[MLton-user] signal handlers

[Matthew Fluet]

On Sat, 1 Dec 2007, Wesley W. Terpstra wrote:
> On Dec 1, 2007, at 10:48 PM, Dave Herman wrote:
>> Sweet! One more question: I think I grok the explanation of system call 
>> restart vs. SysErr on pre-emption, but what happens if C code called via 
>> the FFI is interrupted?
>
> MLton will execute the signal handler once you return from C to SML.

Correct.  When you call MLton.Signal.setHandler, the runtime system calls 
signal() and installs a (trivial) signal handler that does nothing but set 
the heap limit pointer to 0 and records the identity of the signal in 
global state.

Hence, when a signal is delivered, the running C or ML code is 
interrupted, the runtime installed signal handler runs (and does its 
thing), and the running C or ML code is resumed.  At some point, when the 
running code is in ML, it fails a limit check, enters the runtime, which 
recognizes that a signal has been delivered, and then sets things up to 
run the ML signal handler.

The thing with system calls is that they aren't oblivious to the arrival 
of a signal, so there is some complication to get them to be well-behaved 
(from the point of view of the Basis Library and the ML code).  'Normal' C 
code (indeed, any user code) is oblivious to the arrival of a signal; the 
C signal handler runs and then the interrupted code is resumed as if 
nothing had happened.  (Or, more accurately, in order to see that 
something had happened, it needs to inspect some shared mutable state.)