From ce68c88e0aea4ab08542d5ccf0bbc0349a382694 Mon Sep 17 00:00:00 2001 From: Julian Noble Date: Fri, 27 Sep 2024 04:30:53 +1000 Subject: [PATCH] comment only re stdout/stdin in repl::doprompt --- src/modules/punk/repl-0.1.tm | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/modules/punk/repl-0.1.tm b/src/modules/punk/repl-0.1.tm index eef8799d..4538d130 100644 --- a/src/modules/punk/repl-0.1.tm +++ b/src/modules/punk/repl-0.1.tm @@ -615,7 +615,8 @@ proc repl::doprompt {prompt {col {green bold}}} { flush stdout; #we are writing this prompt on stderr, but stdout could still be writing to screen #our first char on stderr is based on the 'lastchar' of stdout which we have recorded but may not have arrived on screen. #The issue we're trying to avoid is the (stderr)prompt arriving midway through a large stdout chunk - #REVIEW - this basic attempt to get stderr/stdout to cooperate is experimental and unlikely to achieve the desired effect + #REVIEW - this basic attempt to get stderr/stdout to cooperate is experimental and unlikely to achieve the desired effect in all situations + #It the above flush does seem to help though. #note that our 'flush stdout' tcl call does not wait if stdout is non-blocking #todo - investigate if the overhead is reasonable for a special channel that accepts stdout and stderr records with a reader to send to console in chunk-sizes we know will be emitted correctly # - reader of such channel could be ok to be blocking (on read? on write to real channels?)... except everything still needs to be interruptable by things like signals?