[slime-devel] communication-style nil and interrupts

[Helmut Eller]

* Tobias C. Rittweiler [2010-03-08 17:35+0100] writes:

> Currently, we use NIL on ECL because on one hand while it has threads,
> some parts are not yet thread-safe, and on the other hand, I do not
> fully understand Slime's :fd-handler architecture. 
>
> :FD-HANDLER seems to be tied to an I/O-implies-serve-event architecture
> like SBCL (and CMUCL?) have. OTOH, I just took a courtesy look at
> WAIT-FOR-INPUT in swank-cmucl and see *INTERRUPT-QUEUED-HANDLER*. What's
> the purpose of that? Why does WAIT-FOR-INPUT write to that pipe? :-)

Hmm... can't quite remember.  Maybe a thinko, as serve-event should
return automatically if an interrupt happened.

> ECL does have a select()-based serve-event, but it's not implicitly
> called. Where in the backend should it call serve-event?

serve-event is mainly called by the listener of CMUCL/SBCL when it waits
for input.  read-char etc. implicitly call wait-until-fd-readable, which
calls serve-event to wait.  

The other time it's called when the debugger waits for input with the
backend function wait-for-input.

> The problem with NIL is that if ECL was built with threads enabled, it
> executes the SIGINT handler function inside a new thread. But we
> actually want to interrupt the REPL thread -- however SIGNAL-INTERRUPT
> just ignores its thread argument in case :SPAWN is not used. So I do not
> see an obvious way out.
>
> That said, the problem won't be solved by implementing :FD-HANDLER for
> ECL either.
>
> Thoughts?

Maybe the sigint handler could use swank-backend:interrupt-thread to do
it's thing in the proper thread.

Helmut