Sockets are registering semaphores in external object table, to be able signaled by socket plugin. When image starting after booting VM, an external object table is cleared and replaced by empty fresh array. So, if there is any process(es) left in saved image which waiting on such semaphores to be signaled via external event (as sockets), they will never awake, because there's no one who can signal them. To get around problem, at startup phase, we should do something like that: Socket allInstancesDo: [:s | s signalAndClearSemaphores ]. So, any process which has waiting for given semaphores will have a chance to get past the lock and die.
As for gracious shutdown/startup, to prevent interrupting process which saving image by some process who can handle network requests, i think best way is to suspend all active processes except one, which saving image. And then resume them after save done. But lately, when i tried to do it myself, i found that it's not possible, due to bug in #resume: (see other discussion about suspend/resume). So, we need to wait until it will be fixed, or find a way around.
On 24/12/2007, Andreas Raab andreas.raab@gmx.de wrote:
Lukas Renggli wrote:
The doIt you sent comes out empty, I've never seen a case where it actually returned a process. For the stack dumps I've got only the attached screenshot from the process browser that I took December 5., roughly a month after loading your patches.
Unfortunately, the screenshot doesn't show much interesting - the best thing to do is to cover *all* processes when the system is locked up for forensic analysis. What we have done in our server VMs is to hook up the USR1 signal to the VM's printAllStacks() function so that we can simply get a stack dump via kill -USR1 <pid_of_squeak>. I don't know if this is in the standard Unix VMs (I have no idea how portable the code is) but it's a must have feature for running a Linux server with Squeak.
Current versions of the Kom server adapter for Seaside stop listening while saving the image, but I have to check if this is also the case with the version of Seaside used in squeaksource.com.
That's a likely cause for problems. Also, you probably need to make sure all requests are finished before saving the image - otherwise some of them may rely on network activity to wake up.
Cheers,
- Andreas