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.
Thanks for the explanation. So, you'd like to set *invoke-debugger-hook* in one thread and make the change visible in the other threads, right? I guess then we need a set-invoke-debugger-hook slimefun, similar to set-package. Hmm... and probably a hook to detect when Emacs disconnects.
A secodary but probably solvable issue is that as currently implemented the sldb-loop blocks all serve-event processing, so new requests aren't getting answered when the debugger is active. This is for the moment livable with (and saves us from implementing the lock on the debugger that's next on the hacking list) but if simply connecting slime to the process is henceforth going to freeze it, that's not so great.
This should go a away if the file-descriptor is non-blocking.
Not so wild about multiple TCP connections. My ultimate goal is to be able to slime across a network, which may require SSH tunnelling or other interesting configurations,
Neither am I. But there are some advantages if we use multiple connections. E.g, we could use the same code for multi-threading support as for "multiple Lisp processes" support, locking would be easier, and we could disconnect if something goes wrong in one thread without disturbing the other threads. OTOH, Erlang seems to use a single connection for all threads. Maybe we should just steel whatever they do.
Helmut.