[MLton] cvs commit: better blocking/unblocking of signals in runtime and basis

[Stephen Weeks]

>   Keep gcState.signalsBlocked in sync with the user program.
>   To do so, we keep an ML side representation of the currently blocked
>   signals.

I notice that the initial value of the blocked signals mask is
Signal.Mask.none.  I wonder if it would be better to call sigprocmask
to find out the current mask and use that instead?  This is what we do
for initializing our ML-side representation of the signal handler
array.

> Upon a MLton.Signal.Mask.{block,unblock,setBlocked}, we
> compute the new set of blocked signals and call sigprocmask with
> SIG_SETMASK.

I wonder of it makes sense, given that there is more computation going
on now, to represent masks with bool array (or even word array)
instead of signal list.  Also, would the name Sigset be better than
Mask?

I think a better name for Mask.member is Mask.isMember or even
Mask.hasSignal (to be consistent with other parts of the MLton
structure that use "are", "has", or "is" to indicate a predicate).

>   2) MLton.Signal.Mask.getBlocked (and the ML side representation) do
>        not reflect the blocking of signals during the execution of a
>        signal handler.  This is easily changed, but it seems more
>        natural this way.

I don't know.  As it stands, it's at least worth a note in the user
guide.

>  static inline void blockSignals (GC_state s) {
>  	if (shouldBlockSignals ())
> -		sigprocmask (SIG_BLOCK, &s->signalsHandled, &s->signalsBlocked);
> +		sigprocmask (SIG_BLOCK, &s->signalsHandled, NULL);
>  }

I guess it doesn't matter, but SIG_SETMASK might be clearer here.

> +Int Posix_Signal_sigprocmask () {
> +	gcState.signalsBlocked = set;
> +	if (gcState.inSignalHandler)
> +		return 1;
> +	return sigprocmask (SIG_SETMASK, &set, (sigset_t*)NULL);

I don't understand why 1 is returned if gcState.inSignalHandler.
sigprocmask is supposed to return 0 on success and -1 on error.  We
could try to figure out what it should mean to block/unblock signals
while running a handler -- until we figure this out, we could raise an
exception if someone tries to do so.