[Ecls-list] Revisiting locks and signals

[Juan Jose Garcia-Ripoll]

On Fri, Jan 14, 2011 at 2:25 PM, Matthew Mondor <mm_lists at pulsar-zone.net>wrote:

> On Fri, 29 Oct 2010 23:56:33 +0200
> Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com> wrote:
> > a* The SIGINT handler always jumps to an outer point in the lisp code.
> > b* Similar as "a" but only when the function is marked interruptible.
> > c* Similar as "a" but the thread is paused and in a separate thread a
> > debugger is started, from which we can decide whether to jump to an outer
> > point.
>
> When you say an outer point, do you mean something like
> [sig]longjmp or sigaltstack, used when the user/code decide that
> unwinding must be done?
>

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.

It seems reasonable to me to still use a SIGINT handler (at least
> as an option) and leave responsibility to user code for any unwinding
> and state issues...
>

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.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20110114/e0601710/attachment.html>