signal handling and save world

[Stephen Weeks]

> In playing with the profiler, I thought I would try profiling mlton.  I
> discovered one thing -- the profiler signal handler is not installed when
> restoring a world.  I migrated /src/runtime/gc.c#initSignalStack from
> GC_init to GC_initCounters so that it is invoked when restoring a world.
> This was probably a bug -- because there's no reason that receiving a
> signal when %esp is pointing to non-stack code can't happen when running a
> restored world.  It should also now start and use the profiler when
> running a restored world.

Cool.  This must have worked at one point because I know we profiled mlton, but
I guess it broke with the native profiler.

> Although I hadn't thought of it before, I guess that when restoring a
> world, none of the handlers installed in the previous run will be
> installed.  Just struck me as interesting that that aspect of the state of
> the program won't be restored.

Yes, that's what happens according to src/basis-library/mlton/signal.sml, but I
can't remember the justification.  Here's an old mail exchange between me and
Henry that would seem to imply that we decided to restore them.  I'm not sure
why that's not done.

--------------------------------------------------------------------------------

From: "Stephen Weeks" <sweeks@wasabi.epr.com>
To: Henry Cejtin <henry@clairv.com>
Subject: save world and signals
Date: Tue, 14 Dec 1999 23:13:17 -0800 (PST)


What do you think the right thing to do is with all of the signal
handlers when saving/loading the world?

--------------------------------------------------------------------------------

From: Henry Cejtin <henry@clairv.com>
To: sweeks@intertrust.com
Subject: Re: save world and signals
Date: Wed, 15 Dec 1999 01:24:29 -0600

Hm, interesting question.  One approach would be to just restore them to what
they were.  An alternative, probably better, but a bit DWIMish, would  be  to
take  what they were, and restore any that aren't currently ignored.  I guess
that I would vote for that, but print a warning to stderr about ones that are
going to be left ignored.

--------------------------------------------------------------------------------

From: "Stephen Weeks" <sweeks@wasabi.epr.com>
To: Henry Cejtin <henry@clairv.com>
Subject: Re: save world and signals
Date: Tue, 14 Dec 1999 23:29:49 -0800 (PST)


> Hm, interesting question.  One approach would be to just restore them to what
> they were.  An alternative, probably better, but a bit DWIMish, would  be  to
> take  what they were, and restore any that aren't currently ignored.  I guess
> that I would vote for that, but print a warning to stderr about ones that are
> going to be left ignored.

And you take both of these over just flushing all the signal handlers
upon save world and not restoring anything?

--------------------------------------------------------------------------------

From: Henry Cejtin <henry@clairv.com>
To: sweeks@intertrust.com
Subject: Re: save world and signals
Date: Wed, 15 Dec 1999 01:39:33 -0600

I think so.  The argument is that if I am catching some signal when the world
is saved, wouldn't I still want to catch it when the world is restored?  Of
course it might not be appropriate any more, but usually, ...
For things like this (and current directory, etc.) it might make sense to have
a saved world include an initial text segment which could be edited.
A bit gross, to say the least.  I guess it all depends on what save-world is
meant to serve: checkpoint/restart?  Computation staging?  Something else?

--------------------------------------------------------------------------------

From: "Stephen Weeks" <sweeks@wasabi.epr.com>
To: Henry Cejtin <henry@clairv.com>
Subject: Re: save world and signals
Date: Tue, 14 Dec 1999 23:43:35 -0800 (PST)


> A bit gross, to say the least.  I guess it all depends on what save-world is
> meant to serve: checkpoint/restart?  Computation staging?  Something else?

Both.

Right now, I use it for the latter in the compiler to process the
basis library and save the world to be used for all subsequent
compilation.

Soon, you will be using it for the former for doing checkpointing of
long running computations.  (I just have to do a little bit more
finagling to get saveWorld to work right within a signal handler.)

--------------------------------------------------------------------------------

From: Henry Cejtin <henry@clairv.com>
To: sweeks@intertrust.com
Subject: Re: save world and signals
Date: Wed, 15 Dec 1999 01:47:06 -0600

The point is that for checkpoint/restart, you want to restore pretty much
everything.  For staging computation, you don't since it really is a different
stage that you restart.

--------------------------------------------------------------------------------

From: "Stephen Weeks" <sweeks@wasabi.epr.com>
To: Henry Cejtin <henry@clairv.com>
Subject: Re: save world and signals
Date: Tue, 14 Dec 1999 23:48:50 -0800 (PST)


> The point is that for checkpoint/restart, you want to restore pretty much
> everything.  For staging computation, you don't since it really is a different
> stage that you restart.

OK.  Then I propose adding a flag to the signals structure that
controls the behavior.  Say
	val saveSignalsInWorld: bool ref
If true, this does your DWIM thing.  If false, it flushes 'em all.

--------------------------------------------------------------------------------

From: Henry Cejtin <henry@clairv.com>
To: sweeks@intertrust.com
Subject: Re: save world and signals
Date: Wed, 15 Dec 1999 01:57:01 -0600

I guess, but other than a small race condition, there isn't much saved.
I.e., the false case just means I test the response from save-world and if
I am restarting, I set the signals I want.  The race is signals that arrive in
that window between when the world is restarted and when I can do something
about it.  I guess that the really safe thing would be to start them all
blocked, but that is pretty gross, and there would still be a window.
I hate multiple threads, and this really is the same thing.
What would you use the saveSignalsInWorld=false stuff for?

--------------------------------------------------------------------------------

From: "Stephen Weeks" <sweeks@wasabi.epr.com>
To: Henry Cejtin <henry@clairv.com>
Subject: Re: save world and signals
Date: Wed, 15 Dec 1999 00:00:10 -0800 (PST)


> What would you use the saveSignalsInWorld=false stuff for?

Staged computation :-)

But since I don't really have a use in mind, maybe I'll just go for
your DWIMish thing for now.

--------------------------------------------------------------------------------

From: Henry Cejtin <henry@clairv.com>
To: sweeks@intertrust.com
Subject: Re: save world and signals
Date: Wed, 15 Dec 1999 02:08:28 -0600

I would do that for now, but issue the stderr warning if you don't restore some
handlers because they are currently ignored.

--------------------------------------------------------------------------------