[Ecls-list] Ecl does not react on SIGINT on Linux

Tobias C. Rittweiler tcr at freebits.de
Mon Mar 8 10:27:44 UTC 2010


Juan Jose Garcia-Ripoll
<juanjose.garciaripoll at googlemail.com> writes:

> On Mon, Mar 8, 2010 at 12:41 AM, Tobias C. Rittweiler <tcr at freebits.de>wrote:
>
>> We overwrite si:terminal-interrupt in Slime. May there be a better
>> solution involving that servicing thread in case ECL was built with
>> threads?
>
>
> No, there is none. The servicing thread is not a normal lisp thread. It runs
> with interrupts disabled and polls for asynchronous signals using sigwait().
> This is mandated by POSIX. Any other way is deemed unsafe, for signal
> handlers can not execute almost any C function -- and by that rule, they can
> not execute arbitrary lisp code.
>
> Indeed the problem is the single-threaded version of ECL, which is not POSIX
> compliant in this respect. And from what I know about other lisps, they are
> also not POSIX compliant, even in the multithreaded case. This includes the
> whole process-interrupt business which is available in lisp implementations,
> including ECL: it is a nasty function and should be banned completely, as it
> causes a lot of problems from the implementation point of view, leading to
> horrible hacks and performance sinks.

In what dynamic context is TERMINAL-INTERRUPT executed? From what I'm
seeing (or rather not seeing :-)), it seems to be executed in an empty
context?

OTOH:

> (with-simple-restart (foo "FOOF!!") (loop (sleep 10)))
^C
Console interrupt

Available restarts:

1. (CONTINUE) CONTINUE
2. (FOO) FOOF!!
3. (RESTART-TOPLEVEL) Go back to Top-Level REPL.

Hmm, gotta look into the source of the native TERMINAL-INTERRUPT if it
does anything special...

  -T.





More information about the ecl-devel mailing list