On Thu, May 17, 2012 at 07:29:29PM -0700, Sean P. DeNigris wrote:
> 
> David T. Lewis wrote
> > 
> > the VM is blocking on a read from an OS pipe...
> > 
> > 0xff7d49a0 M ExternalPipe>upToEnd -1053201688: a(n) ExternalPipe
> > 0xff7d49c0 M [] in PipeableOSProcess>closePipes -1053202016: a(n)
> > PipeableOSProcess
> > 
> 
> #closePipes is calling #upToEnd. Could this be another case of failing to
> call #setNonBlockingOutput?

Good catch Sean, that's exactly what's happening. The #closePipes does
a few things in addition to closing the pipes, because it is intended
for use in a process pipeline. Specifically, it is used to clean up
the pipes for the last process in a pipeline of processes, in which
case the output of that last process will have been set to nonblocking.

I'm not sure that this is a case of failing to call #setNonBlockingOutput
(because in general the output of an external process *should* be in
blocking mode). But calling #upToEnd on a blocking file stream will
lock up the VM if no data is available, and that's exactly what is
happening here.

This should be preventable ... hmmm ... 

Dave