I am trying to use serve-event to interactively monitor network protocols but i'm facing some issues when trying to work on the slime repl:
1) On threaded sbcl + :spawn swank comm style, serve-event does not run at all on the repl thread (the thread seems to be blocked on a call to condition-wait, in receive-if/swank-sbcl.lisp)
I tried modifying receive-if so that it serves all pending events before acquiring the lock but i guess this could prove to be problematic.
2) Also tried scheduling a timer to interrupt *current-thread* (repl thread) and run serve-all-events periodically which works but i guess this is even worse than 1) and could explode pretty easy.
3) Using :fd-handler (and therefore a single thread) it seems that slime completely takes over the event loop and does not allow other handlers to run unless there is input coming from the repl. (Blocking on read-sequence ?)
I could give up :spawn and work with :fd-handler comm style, if slime would let other handlers run and not block without configurable timeout at least. Is this feasible ? Where would one start looking in order to implement it ?
Chris
* xristos [2009-02-15 06:02+0100] writes:
[...]
I could give up :spawn and work with :fd-handler comm style, if slime would let other handlers run and not block without configurable timeout at least. Is this feasible ? Where would one start looking in order to implement it ?
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.
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. SLIME blocks when the debugger needs to waits for input, but that can only happen after the fd-handler is called (or after an interrupt, but let's ignore that). If you actually need nested event-loops things get complicated quickly, especially if interrupts are involved.
With :spawn style SLIME doesn't touch SERVE-EVENTS.
Is there a problem if you run the event-loop in your own thread?
Helmut.
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
* xristos [2009-02-15 17:32+0100] writes:
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).
Well then, why don't you call SERVE-EVENT somewhere in your application?
Helmut.
-
Helmut Eller -
xristos