[Ecls-list] Revisiting locks and signals

[Matthew Mondor]

On Fri, 29 Oct 2010 23:56:33 +0200
Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com> wrote:

> Mathew, let me try to explain again what is the problem and a possible
> operation model.
[...]

Sorry for not having answered earlier, back when I received the message
I couldn't take the time to seriously read it and had placed it on an
important-to-read queue.  I now could finally read it.

> 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?

> So it seems it would be possible to execute ECL threads that run with
> interrupts mostly disabled. Signal handlers would do very little, and only
> in the undesirable situations would they allow jumping to outer parts of the
> code or canceling the thread (unwinding any possible operations), but that
> would be done placing the burden of possible side-effects on the user.
> 
> This would have a couple of positive side effects. One would be that it
> would make coding a lot simpler. Most of ECL right now is not
> async-signal-safe and it will probably never be. Lisp code also can't be
> async-safe. Instead of revisiting all the code, filling it with
> ecl_disable_interrupt() calls, which are costly, we would be able to get a
> cleaner Lispwhere everything is assumed to run properly, except in weird
> situations.
> 
> It might also help us in thinking of simpler ways to integrate ECL with
> foreign signal handlers, specially when embedding -- since ECL threads do
> not expect signals, or only serious ones with a specific protocol (unwind or
> exit) it would make embedders' lives easier.

I agree with these previous paragraphs.

I also need to think more about the endless loop interruption issue,
which can indeed be a problem in interactive environments where one is
expecting to regain control on demand.  And even if the lisp side could
attempt to use heuristics based on something like the history of lock
operations or various other state parameters, this would still be
problematic in any foreign code, unless is was forced to also use the
same custom API...

But I also dislike the idea of checking at loop points and the
like; it wouldn't work in a number of cases anyway.

And if a minimal SIGINT handler was optionally provided, which would
only add a message to a queue for another dedicated thread in a loop
based around 1-second sleep(3) calls and occasionally checking, would
there be any advantage?  If the user decides that it must be
interrupted anyway, it seems like a chicken-and-egg problem as another
signal would need to be used to unblock it, and it doesn't solve any
unwinding/state problems if it has to jump out.

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...
-- 
Matt