Daniel Barlow dan@telent.net writes:
I don't think that's going to work in the context I have in mind: a long-lived server to which SLIME is connected periodically for debugging or upgrades. In a multithreaded server, all my request-answering processes are in their own threads which were started outside of a SLIME connection (perhaps at boot time) and will probably last for longer than the current SLIME session. Perhaps for HTTP it wouldn't hurt too much to tear them down and create new ones in a SLIME context, but for some more stateful protocol it'd be more pain.
What setup are you with right now - is it multithreaded?
I'm wondering if you're binding *invoke-debugger-hook* globally for all threads (with potential race conditions), or if you're starting with a simpler somehow.
Also,
In a single-threaded SERVE-EVENT-based system, it might be nice if SLIME goes into an infinite loop as Helmut says, but is calling SYS:SERVE-EVENT instead of READ-FROM-EMACS. i.e. the usual SERVE-EVENT loop is running and serving the REPL, webserver, etc, but all within SLIME's dynamic binding setup. When the SLIME socket closes, we throw back out. (Or is that what you meant, Helmut?)
-Luke