On Fri, 29 Oct 2010 23:56:33 +0200 Juan Jose Garcia-Ripoll <juanjose.garciarip...@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 ------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
