[slime-devel] thread manipulation

[Marco Baringer]

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