[slime-devel] thread manipulation
mb at bese.it
Sun Feb 29 10:06:12 UTC 2004
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
> Is this a swank server or some other server without a connection to
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
> 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.
Ring the bells that still can ring.
Forget the perfect offering.
There is a crack in everything.
That's how the light gets in.
More information about the slime-devel