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? :-)
ECL does have a select()-based serve-event, but it's not implicitly called. Where in the backend should it call serve-event?
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?
-T.
* 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
-
Helmut Eller -
Tobias C. Rittweiler