An interactive program that wants to handle interrupt itself should not
rely on default signal behavior, because that has no idea where to stop
(and I would argue that attempting to coerce interactive signals into
exceptions within the program is not the right way to do things, because
they're only superficially similar and oddities like this are the result).
 If you want to handle signals, handle signals; don't rely on exceptions to
do it for you.

Using the POSIX model, signals are blocked until the handler either returns
or modifies the signal mask explicitly; this prevents a race condition
which in this case could happen when a program is running slowly due to
some other process slowing the machine down, which could lead to a second
SIGINT aborting the program before the program could handle it.  (This used
to be common on AT&T/v7-derived Unixes which didn't have signal blocking,
and is why POSIX adopted the BSD-derived signal model.)  If you try to map
signals to exceptions, you can't make them behave like an exception (where
a second one, received while in the exception handler, is thrown
immediately to the outer scope) without losing the ability to handle that
signal inside the exception handler (due to the race condition above).

(I have a feeling I'm not describing this clearly enough; I'm a bit fuzzy
due to not having caught up on sleep fully yet.)

Possibly the way to do a higher level signal handler is something similar
to "catch":

    computation `withSignal` $ \sig -> handler

where, unlike "catch", the signal is blocked until "handler" finishes
unless explicitly unblocked (thus behaving like POSIX signal handlers and
avoiding the race condition).

(And then comes the question of how, if at all, any of this applies to
Windows, which I'm unqualified to answer.)

-- 
brandon s allbery                                      allber...@gmail.com
wandering unix systems administrator (available)     (412) 475-9364 vm/sms
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply via email to