On Fri, Jan 14, 2011 at 2:25 PM, Matthew Mondor <span dir="ltr"><<a href="mailto:mm_lists@pulsar-zone.net">mm_lists@pulsar-zone.net</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

On Fri, 29 Oct 2010 23:56:33 +0200<br>
<div class="im">Juan Jose Garcia-Ripoll <<a href="mailto:juanjose.garciaripoll@googlemail.com">juanjose.garciaripoll@googlemail.com</a>> wrote:<br>
> a* The SIGINT handler always jumps to an outer point in the lisp code.<br>
> b* Similar as "a" but only when the function is marked interruptible.<br>
> c* Similar as "a" but the thread is paused and in a separate thread a<br>
> debugger is started, from which we can decide whether to jump to an outer<br>
> point.<br>
<br>
</div>When you say an outer point, do you mean something like<br>
[sig]longjmp or sigaltstack, used when the user/code decide that<br>
unwinding must be done?<br></blockquote><div><br>It would be a kind of "error handler", or more precisely a "catch" point, just like the ones that unwind-protect sets up. Such places could be the destinations of a long jump (longjmp) that simply exits the signal handler, leaving things in whatever state (consistent or not) they were.<br>

<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
It seems reasonable to me to still use a SIGINT handler (at least<br>
as an option) and leave responsibility to user code for any unwinding<br>
and state issues...<br></blockquote></div><br>This sentence somehow remarks how subtle the problem is: "leave responsibility to user code for any unwinding..." The problem is that if we assume SIGINT interrupts may happen at any point, and unwinding too, there isn't much that the user code can do. Most probably it is going to be *system* code (not user code) which is going to be affected: garbage collectors, object instantiation and initialization, resources grabbing, etc, etc. So once this "option" has to be considered, the resulting code bears a rather severe burden and becomes messy: interrupts activation and deactivation everywhere, interrupt checking, etc, etc. This is quite a performance hit, specially when it comes to memory allocation and resource initialization.<br>

<br>Juanjo<br clear="all"><br>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://juanjose.garciaripoll.googlepages.com" target="_blank">http://juanjose.garciaripoll.googlepages.com</a><br>