<div dir="ltr"><div>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&#39;re only superficially similar and oddities like this are the result).  If you want to handle signals, handle signals; don&#39;t rely on exceptions to do it for you.</div>
<div><br></div><div>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&amp;T/v7-derived Unixes which didn&#39;t have signal blocking, and is why POSIX adopted the BSD-derived signal model.)  If you try to map signals to exceptions, you can&#39;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).</div>
<div><br></div><div>(I have a feeling I&#39;m not describing this clearly enough; I&#39;m a bit fuzzy due to not having caught up on sleep fully yet.)</div><div><br></div><div>Possibly the way to do a higher level signal handler is something similar to &quot;catch&quot;:</div>
<div><br></div><div>    computation `withSignal` $ \sig -&gt; handler</div><div><br></div><div>where, unlike &quot;catch&quot;, the signal is blocked until &quot;handler&quot; finishes unless explicitly unblocked (thus behaving like POSIX signal handlers and avoiding the race condition).</div>
<div><br></div><div>(And then comes the question of how, if at all, any of this applies to Windows, which I&#39;m unqualified to answer.)</div><div><br></div>-- <br>brandon s allbery                                      <a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a><br>
wandering unix systems administrator (available)     (412) 475-9364 vm/sms<br><br>
</div>