[squeak-dev] Does PipeableOSProcess require some finalization/clean up?

Yoshiki Ohshima Yoshiki.Ohshima at acm.org
Thu May 17 16:54:11 UTC 2012


At Thu, 17 May 2012 10:16:53 -0400,
David T. Lewis wrote:
> 
> 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 ...

Just another data point: the crash report shows that VM is blocked on
a read on Mac, too.

-- Yoshiki


More information about the Squeak-dev mailing list