signals in MLton

[Stephen Weeks]

> What was the motivation to include a general signal handling
> facility?

To be able to write "trap" expressions in mlsh scripts, and to be able 
to handle signals in daemons.

> Is it because you want to include stuff like timer 
> interrupts (for implementing threads via call/cc)?  

Yes, preemptive multithreading would be nice as well, although there
are still a couple of other obstacles (see below).  I wouldn't quite
do it using callcc, since that is a bit slow in MLton, but it should
be easy enough to provide the hooks to ML in order to allow many
stacks to exist simultaneously and to have a constant time operation
to switch the "current" stack.

> I don't 
> suppose it's to handle general gc since I thought the poll 
> checks at loop entry points worked well; was I mistaken here?

You were not mistaken.  The limit checks at various places work fine.

The main obstacle to using signals to implement threads is that the
runtime system is not called via the trampoline like other interchunk
calls -- instead, a normal C call is used.  This was done for
(possibly bogus) performance reasons because it means that C locals
will be preserved on the C stack over the GC call.  Unfortunately, it
also means that not all of the information needed to be saved in order
to do a context switch is available to the GC.  So, I propose to
change the implementation so that a GC call is a normal interchunk
call.  The main impact would be that fewer (possibly much fewer) Cps
variables would be kept in C locals than under the current register
allocator.  However, it would clean up the interface to the runtime
system a bit and would make multithreading feasible.

The other thing that would need to be done would be to move the stack
into the heap, and then to allow multiple stacks (almost what we
currently have with callcc, except that the stacks created by callcc
have no spare space to continue running).  This seems pretty easy to
do, and would also alleviate Henry's complaints about the stack memory 
coming from a separate pool than the heap memory.  It would stress the 
GC a bit more, having to copy the stack(s) at each GC, but such stress 
would be no bad thing.