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

[Matthew Fluet]

> > > > +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.
> >
> > I meant for it to return success, so it should return 0.
>
> OK.  I wonder if it would be clearer to skip the creation of the
> sigset and the call to sigprocmask from the ML side?

It really depends on what we want to happen when block/unblock-ing
signals while running a handler.  Given the way the MLton.Signal library
is designed, I would want it to have essentially the same semantics as
what happens when you  sigprocmask  while in a C handler installed by
sigaction.

The reason it matters, is that if we allow the set of blocked signals to
be changed in a handler, then we still need to update
gcState.signalsBlocked, so that when the runtime leaves the ML signal
handler, it will restore the correct set of blocked signals.  In that
case, we're still building the sigset and only skipping the call to
sigprocmask.