On Sabato, feb 28, 2004, at 22:19 Europe/Rome, Helmut Eller wrote:
here's the use case: i start a server with 20 worker threads, occasionally these threads will get into an inconsistent state, causing an error the next time the thread attempts to service a request.
Is this a swank server or some other server without a connection to Emacs?
sorry, this isn't clear: I start an uncommon web server from the termianl. The first thing i do is start a "regular" swank server (swank:create-swank-server) and then M-x slime-connect. At this point I have ucw which has 20+ active threads. For some reason the value of *default-application* in thread 13 turns into something which isn't an application object. I'd like to be able to get (describe and manipulate via a repl) the value of various dynamic variables in thread 13.
I want to be able to jump into the thread, examine some special variables, fix what needs to be fixed and then continue.
slime-thread-debug and the usual debugger commands could be used for this, right? This wouldn't give you a REPL, tough.
yes, slime-thread-debug and eval in frame could be used, it's just not quite as convient.
My idea was to simply interrupt the thread, start a single threaded slime server and then when i was done return from the interuppting function and let the worker thread keep going. The patch i applied is missing that last piece of functionality, but i'm not sure this is the right way to go about things so i'll wait to hear what you think.
Ahh... now I see what you want to do. You'd like to open a new connection that doesn't use a control thread, but uses the same technique as we do for CLISP. Is that about right?
yes, that's exactly the idea. This was why i changed the arglist of swank:start-server to take the optional background arg.
That could indeed work. There are some problems, though. You have to make sure that nothing bad happens with *emacs-connection*. It's probably enough if you bind it in the debuggee, before starting the server. And it's probably also a good idea to bind *emacs-connection* when you debug the thread trough the control thread. Interrupting is also a somewhat delicate issue. For CLISP we use SIGINT and this might not work so well with multiple threads.
[BTW, why do you want a new REPL? I rarely use it and don't quite understand why other people seem to like REPLs so much.
It's just for me to be able to eval functions, describe things and set things; I'm pre-emptevly debugging and the repl is a convient way to do this.
If you just want that all commands you type to the (normal) REPL are evaled in a particular thread, it should be enough to set slime-current-thread in the REPL buffer.]
unfortunetly slime-current-thread needs to be a member of *active-threads* and *active-threads* contains only the thread swank has started, not all the active threads in the lisp image. Of course, it wouldn't be hard to add the thread to *active-threads*, if this is a better way to go about things.
-- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen