Hi Chris,

A few comments below, just personal opinions.

On Mon, Apr 27, 2015 at 09:59:00PM -0500, Chris Muller wrote:
> 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.

This is a good feature, and the stack print from Cog is very useful. There
is a similar stack print in the interpreter VM, though not as good as the
Cog one, and it requires OSProcess to activate it.

	"OSProcess accessor setPrintAllStacksOnSigUsr1"
	"OSProcess accessor clearPrintAllStacksOnSigUsr1"

In terms of out of the box behavior, neither approach is very good.

Requiring OSProcess to activate the handler in the VM is bad, because
nobody (including me) will ever remember to set that up, so it will never
be there when you really need it (stuck image, want to look at the stack).

Having it hard wired to SIGUSR1 in the VM is not good either, because
SIGUSR1 might be needed for some other purpose (e.g. a third party library
linked to a VM plugin).

A better approach would be to have it active by default, but control it
with a command line option to the VM (for all Unix VMs). That way the
feature can be available for everyone out of the box, but it can be
disabled or reconfigured to use a different signal number in cases where
SIGUSR1 might be needed for some other purpose.

> 
> 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.

It's a good idea, but proceed with caution. If someone sent a SIGTERM to
you, it means they want you to terminate real soon now. If you ignore
that advice, you do so at your own peril.

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

I appreciate the sentiment, but I really think that OSProcess is best
maintained as a separate package :-) Bits and pieces might be adopted
where useful, but I really would not want to see Squeak turn into a YAUK
(yet another unix klone). Besides, we have SqueakMap so it is easy to
load packages like this.

Dave

> 
> 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
> >