[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.)