Implementation Specific Behavior for LAUNCH-PROGRAM Output Streams
I was trying to use launch-program
to programmatically interact with another process's REPL and stumbled across some behavior that is implementation dependent. I was wondering if we should note it in the doc string and/or provide some mechanism to smooth over the differences.
When passing non fd-backed streams to :output
or :error-output
, the implementation can't in general pass that stream directly the child process to write to. Instead, the parent has to set up a pipe and shuffle bits from the pipe to the stream where you want the output to go. SBCL doesn't shuffle those bits until you wait-process
or serve-event
. ECL spawns a new thread for each process that constantly does the shuffling. I haven't dug around in CCL internals yet, but it appears to behave as ECL in my tests.
In my case, I was writing error-output to a non fd-backed stream and using :stream
for the output. On SBCL, when the child produced over 64k bytes of data on error-output (the default pipe buffer size on my setup), the child process would freeze since it couldn't write anything else. I'm currently working around this by writing the error output to a temporary file and reading it when done.
I'm honestly not sure if smoothing over the difference is going to be worth the effort. If we did, the solution would likely be either a function that the user has to call periodically (ugh) or spawn a new thread that handles it (even more ugh since uiop would have to know about threads then).
But a warning might save someone else from pulling out their hair like I did.