Marco Baringer mb@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.