On Mon, Apr 27, 2015 at 6:53 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> On Sun, Apr 26, 2015 at 06:57:51PM -0500, Chris Muller wrote:
>> OSProcess provides the ability to set up and wait on any of several
>> semaphores which will be signaled if the VM process running the
>> current image gets a posix signal.
>>
>> A few years ago I added a handler for SqueakSource's startUp: to set
>> up a response to TERM, like this:
>>
>> restartSigTermHandler
>> SigTermHandler ifNotNil: [ SigTermHandler terminate ].
>> SigTermHandler :=
>>           [ OSProcess accessor restoreSigTerm.
>>           OSProcess accessor forwardSigTerm wait.
>>           SSRepository current log: 'SIGTERM received, shutting down
>> gracefully.'.
>>           self shutDown.
>>           Smalltalk snapshot: false andQuit: true ] newProcess
>>                 name: 'Waiting for SIGTERM for graceful shutdown' ;
>>                 resume
>>
>> But now I want Magma servers to be able to respond similarly whether
>> SqueakSource is loaded in the same image or not.  But if I were to
>> introduce the above into Magma, then if SqueakSource was also loaded,
>> there would either be two processes waiting to shutdown or one of them
>> would run and the other wouldn't.
>>
>> So this led me to ask, what is the best way to handle this in a
>> general fashion?  This is at the process level, so the first answer I
>> came up with was that it would make sense for the out-of-the-box
>> behavior to respond to TERM with a "Smalltalk snapshot: false andQuit:
>> true" so that each framework can do their own proper thing in
>> #shutDown:...   Is this a good idea or what is?
>
> I guess that if you wanted to generalize this, you might follow the
> pattern of the system startUp: and shutDown: processing, and maybe have
> a class that was responsible for holding on to the processes that wait
> for signals. A class could register itself as being interested in SIGTERM
> if it implemented a method #sigTerm that did something to respond to
> that signal.

Yes, that's exactly what I've done.  I put the state in my own class
but it has the same problem -- competition.

That's why I think it makes sense for the VM to call a method or
provide some hook for the image to respond to SIGTERM with a Smalltalk
snapshot: false andQuit: true.  I think it should do this even without
OSProcess loaded.

That way, all frameworks within the image only have to implement their
normal startUp: / shutDown: code, and they get the graceful SIGTERM
shutdown for "free".

> I would be cautious about saving the image in response to a SIGTERM,
> except in the special case of a server image that wanted to do so. It
> is possible to open several VMs on the same image, either on purpose
> or by accident, and you would not want all those VMs to be trying to
> save the same image when you do "killall squeak". And I think that
> SIGTERM is sent to all processes when the system is being rebooted,
> so you would not want to be half way through saving your image when
> the system goes down.

Agreed.  Right now I'm only interested in quitting without saving so
we can support graceful shutdown of Squeak-based servers via SIGTERM.