[MLton] cvs commit: Added PosixError.SysCall structure.

[Matthew Fluet]

> >   There is a little bit of an ordering problem; in that SysCall.syscall
> >   wants access to MLton.Signal.Mask to block and unblock signals when in
> >   a critical section; on the other hand, MLton.Signal needs a lot of
> >   infrastructure to be implemented.
>
> I was thinking that maybe you could split out MLton.Signal.Mask from
> the rest of MLton.Signal, and move it before the definition of
> PosixError.  But I see that the blocker needs to refer to the array of
> handlers and hence drags in a lot of MLton.Signal.  So I don't see any
> way out.  One problem that might result is if a signal interrupts a
> system call that is part of basis library initialization, before
> MLton.Signal has been set up.  It might be better to have the blocker
> simply return, rather than raise an error in this case.

I'm interested in figuring out exactly what system calls are being run as
part of the basis-library initialization.  I guess I can try compiling an
empty program with -drop-pass deadCode, which should keep all the C calls
in the basis.

> I'm more worried that the assignment to blocker in MLton.Signal is
> going to drag in signal handling code into every program, whether or
> not it installs handlers.  To avoid this, I think Mask.handled and the
> assignment to blocker need to be moved into the let that defines
> (getHandler, setHandler, handlers).

I can move the assignment to blocker to the let, but not Mask.handled.

> One thing I've forgotten from our many discussions last month is why,
> when we are in a critical section and need to restart a system call,
> do we only block the signals handled by SML?  It would seem a better
> guarantee of progress to block all signals.  It would also remove the
> dependency of syscall on the signal handling infrastructure, perhaps
> making it possible to split out Signal.Mask.  But I must be forgetting
> something :-(.

Suppose the user has installed a handler for SIG_ALRM, but not for
SIG_INT.  If, while in a critical section, SIG_ALRM gets raised while in
lengthy system call, we need to restart the system call.  If we blocked
all signals, then C-C at the keyboard won't kill the process.

Note, unfortunately, if an ML handled signal arrives while the signals are
blocked, unblocking the signals don't seem to deliver those signals.  So,
we might miss some signals here.

> BTW, another thing I noticed is that syscall is only restarting if the
> error is EINTR.  I think EAGAIN should also cause a restart.

O.k.  In one of the past emails, there is a reference to ERESTART (which I
couldn't find documented anywhere else), but I guess it should have been
EAGAIN.