[Etoys] finalStripping hangs waitForCommand

[David T. Lewis]

On Tue, Jun 16, 2009 at 06:08:58PM +0530, K. K. Subramaniam wrote:
> On Tuesday 16 June 2009 04:52:29 pm David T. Lewis wrote:
> > OSProcess relies on a semaphore to notify it when a child process exits.
> > If you recreate the special objects array, it may be causing OSProcess
> > to lose this connection, hence external processes would appear to never
> > reach the #complete state.
> >
> > Try doing this immediately after recreating the special objects array:
> >
> >         OSProcess accessor initialize
> >
> > This will restart the process that waits on the semaphore, which will
> > hopefully now be waiting on the correct semaphore.
> I tried initialization in recreateSpecialObjects method just after the array 
> got reset. The child semaphore became nil. I also tried it just after the 
> Rebuild send. Ditto. log is attached.

Hi, I'm back. Try this instead:

  Smalltalk recreateSpecialObjectsArray.
  OSProcess accessor
     primForwardSignal: OSProcess accessor primSigChldNumber
     toSemaphore: nil.
  OSProcess accessor initialize.

Explanation: The signal forwarding primitive in OSProcess requires the signal
handler be unregistered, then re-registered, if you change the special objects
array. There is an explanation in the comment of #primitiveForwardSignalToSemaphore.

> BTW, should'nt recreate raise an event to other classes to get them to 
> reinitialize their semaphores?
Well maybe, but really I think this is too much complication for an infrequent
situation. It is very unusual to to call #recreateSpecialObjects, and normally
OSProcess would recover from it anyway just by restarting the image.

> or can OSProcess do a timed poll loop instead of a semaphore?
Actually, it does do exactly this when the primitives are not available.

> Can we discuss this on #squeak?
Sorry, I was away doing other things. But I think the code above will take
care of the problem. Please let me know if it works.

Dave