[slime-devel] thread manipulation

[Helmut Eller]

Marco Baringer <mb at bese.it> writes:

> if it creates a new control thread then it's not what i want.
>
> 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?

> 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.

> 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?

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.

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.]

Helmut.