[squeak-dev] competition for SIGTERM

Chris Muller ma.chris.m at gmail.com
Tue Apr 28 02:59:00 UTC 2015


Squeak 4.6 will currently respond to USR1 by printing all stacks.
That's a nice OOTB feature.  One more would be if it could somehow
respond to SIGTERM with a graceful shutdown instead of an ungraceful
one.

I'm simply interested in Squeak 4.6 having that feature OOTB.  Do
other Linux programs normally respond to SIGTERM by running their exit
code?  Sometimes I notice some of them print a nice exit message when
I press control+c.

If we brought OSProcess into the image we could do it..   :)

On Mon, Apr 27, 2015 at 9:17 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> On Mon, Apr 27, 2015 at 08:50:02PM -0500, Chris Muller wrote:
>> 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.
>
> But why should the VM need to figure this out? That was the whole point
> of the signal forwarding mechanism in OSProcess - forward the signal
> directly to the image, and let the image figure out what to do with it.
>
>    UnixOSProcessAccessor forwardSignal: signalNumber
>         "Set a signal handler in the VM which will signal a Smalltalk semaphore
>         at semaphoreIndex whenever an external signal sigNum is received.
>         Answer a new Semaphore, or nil if unable to set the handler (possibly
>         because it has already been set). A Smalltalk process can wait on the
>         Semaphore, and take action when a signal is detected. See man(7) signal
>         for signal number definitions on your unix system."
>
> The VM support (in the OSPP plugin) consists of signaling a registered
> Smalltalk semaphore when an OS signal (such as SIGTERM) is detected. That
> is all that should be required. If there are issues with how, what, when,
> and by whom that event should be handled, then you are much better off
> figuring that out in the image rather than in the VM.
>
> The basic signal forwarding mechanism could be incorporated into the VM,
> but I don't see any problem with keeping it in a plugin. The mechanism
> is specific to unix systems, so to me it seems like a good thing to keep
> it out of the VM proper.
>
> Dave
>


More information about the Squeak-dev mailing list