[slime-devel] Asynchronous debugging

[Helmut Eller]

Daniel Barlow <dan at 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.