[Etoys] finalStripping hangs waitForCommand
David T. Lewis
lewis at mail.msen.com
Tue Jun 16 20:17:03 EDT 2009
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:
primForwardSignal: OSProcess accessor primSigChldNumber
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.
More information about the etoys-dev