Standalone-pipelining may cut off finite inputs

[valderman]

When doing standalone pipelining, we get a funny readQueue operation, which does not block when the queue is empty but instead jumps to its consume continuation. This is because when the queue is empty, the standalone thread hasn't put anything there yet, but in order to fill the queue, that thread needs some input which the main thread is responsible for delivering - so we jump to produce that input, then try the read again.

Now, if we're reading a finite input source, the main thread may tear through it, dumping all of it into the standalone thread's input queue, essentially reaching EOF. If this happens and the standalone thread still hasn't produced any output, the main thread will try to produce more input for that thread, realize that the input is all gone, and then happily exit. However, the main thread was responsible for reading the other thread's output and doing something with it before writing it into the output buffer - since it already exited, this will now never happen, so the output gets truncated.

We need to figure out a way to keep the main thread running for as long as it's needed.

[gstew5]

Perhaps the main thread should synchronize on the standalone thread exit before itself returning. That is, if there is no input to the main thread, but also no output from the standalone thread, the main thread should continue waiting for output from the standalone thread until the standalone thread signals it's done.

It's also possible that there isn't enough input for the standalone thread to ever make progress, in which case this strategy just won't terminate.