[MLton] interrupted system call
Matthew Fluet
fluet@cs.cornell.edu
Wed, 24 Mar 2004 20:48:05 -0500 (EST)
> > re too expensive, my interpretation of Matthews thought was that we
> > alway run with all signals blocked (more on that below), but when
> > the current code checks to see if a signal has occured, instead we
> > unblock the signals and then immediately reblock them and then check
> > the flag.
>
> My interpretation was that the MLton C signal handler, GC_handler,
> would block all signals (I assume this is OK in a C signal handler, is
> it?). Then, GC_finishHandler would unblock them, as it does now.
> This would prevent a system call from being interrupted by a signal
> more than once.
I meant the latter. But, I don't think you should block all signals,
just the one you received.
> Here's another option: block the signals if the the system call is
> interrupted, so that the restart can't be interrupted.
I don't see why this would be any more efficient than blocking the signal
in the GC_handler and unblocking them at GC_finishHandler. (Other than
the fact that this would leave signals blocked until the system call
completed, even if the ML signal handler got a chance to run.)