On Wed, May 16, 2012 at 07:38:36PM -0700, Yoshiki Ohshima wrote:
> At Wed, 16 May 2012 19:47:15 -0400,
> David T. Lewis wrote:
> > 
> > On Wed, May 16, 2012 at 12:53:26PM -0700, Yoshiki Ohshima wrote:
> > >   Thank you, Dave!
> > > 
> > > I now understand that going through CommandShell was the sanctioned
> > > way of using PipeableOSProcess.  I'll just modify our code to close it
> > > explicitly.  (And it seems to work beter.)
> > > 
> > > I tried clearing the allMyChildren directory but did not seem to free
> > > these fds.  I tried:
> > > 
> > > PipeableOSProcess allSubInstancesDo: [:e | e closePipes]
> > > 
> > > but this do it seems to kill the VM.
> > 
> > Eeek! This should not be happening. PipeableOSProcess>>closePipes uses
> > StandardFileStream>>primCloseNoError: which does an fclose() to close
> > the pipe descriptor. This should be failure-proof, but I might be missing
> > something.
> > 
> > Is this reproduceable? It does not seem to happen on my Linux PC, but
> > maybe it is an intermittent failure of some kind.
> 
> This is reproduceable in my combination of things.  It does not have
> to be allSubInstancesDo:, but allInstancesDo: does it (of course).
> 
> Oh, the trick seems that I shouldn't close the notifier.  Do the
> first part:
> -------------------------
> v := [1 to: 256 do: [:i |
> 		(PipeableOSProcess command: 'echo hello') output.
> 		(Delay forMilliseconds: 50) wait.]].
> v fork.
> -------------------------
> 
> and while the notifier is shown on the screen, evaluate:
> 
> -------------------------
> PipeableOSProcess allInstancesDo: [:e | e closePipes]
> -------------------------
> 

Thanks Yoshiki,

I see it now. I cannot explain what is happening. The system is
behaving as if the VM was blocked on a read, but I don't think
that this is the actual problem. Interesting ...

Dave