signals in MLton

[Stephen Weeks]

> Since  I  don't tend to use call/cc (not part of Sml, you know) I don't think
> it bothers me too much, but no call/cc in signal handlers seems a  bit  ugly.
> Mind  you,  I  agree  that  what  the  continuation should be during a signal
> handler is slightly strange.  Wait, shouldn't it just  be  the  rest  of  the
> signal  handler followed by what ever got `interrupted'.  Is this hard to do?

There are three possibilities for the semantics of callcc in a signal
handler: 
   1. error
   2. get the stack up to the beginning of the handler
   3. get the entire stack

As there is no necessary connection between the running code and the
handler, I think the correct non-error choice is (2), not (3).  If I
do the other stuff for multiple stacks in the heap mentioned in the
previous message, then I will have the signal handler run on its own
stack, and (3) will be the default behavior of callcc.  Although it's
still a bit weird about where the continuation grabbed in signal
handler returns to.  I suspect I will just choose exit (or, in a
multithreaded system, thread termination).

> Is the flow analysis really flow-insensitive?   Pretty  amusing.   Wait,  I'm
> confused here.
> 
> Ah,  you  basically  transformed  the  program to have 2 entry points, one of
> which simply goes indirect through a ref cell.  Amusing.

Yes, although the two entry points only comes up in the Cps IL -- the
flow analysis really did not change at all (the closure converter did
change, though).

> I agree: dump sigset and just use lists of signals.

OK.  There is a minor performance hit, in that the sigset will be
recomputed for each call to block or unblock, but probably
insignificant.