On 15 Feb 2009, at 10:50, Helmut Eller wrote:
I'm not sure what you need. Usually, the "initial" thread blocks in SB-SYS:WAIT-UNTIL-FD-USABLE which calls SERVE-EVENT with both :spawn and :fd-handler. At least that used to be so.
I think that serve-event works on a per thread basis. This means that serve-event must be called from the thread that registered the handlers for it to actually do any dispatching. It behaves like this here anyway.
With :fd-handler style, SLIME registers a fd-handler but doesn't call SERVE-EVENTS directly. SERVE-EVENTS is called by the initial thread which waits for input on *standard-input* in the *inferior-lisp* buffer.
This is not what i've observed here. Using fd-handler, if i call something that registers handlers from the slime repl, my callbacks will never get called /unless/ i give input to slime (typing enter in the repl seems to do it), and i have to do this everytime i want my callbacks to run. So, it appears that slime hijacks the event loop as events are not dispatched asynchronously.
With :spawn style SLIME doesn't touch SERVE-EVENTS.
Is there a problem if you run the event-loop in your own thread?
With :spawn style, if i call something that registers handlers from the slime repl (repl-thread), then these callbacks will NEVER get called period. This is probably because serve-event is never called from the repl-thread (which seems logical as it continuously waits on a lock). Even if i have another thread calling serve-event, nothing changes (event handling seems to be per thread).
Chris