i've just commited a patch which allows you to do "stuff" with the threads in slime-list-threads.
Killing threads: (bound to k in the slime-list-thread menu), simply kill-thread the thread at point. (Only implemented on OpenMCL).
Attaching a slime-repl to a thread: (bound to a in the slime-list-thread menu) This will interuppt the thread, start a (fore ground) server in it and attach to that server in a new repl buffer.
Debugging a thread: (bound to d in the slime-list-thread menu) This will interuppt the thread and then immediatly signal a simple-error putting you in an sldb-buffer. The backtrace will contain a bunch of extra frames intreduced by the simple-error, but all the restarts and frames are there.
This has only been tested on OpenMCL and has, more than once, rendered my original (started via terminal) lisp unusable.
-- 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
On Venerdì, feb 27, 2004, at 13:36 Europe/Rome, Marco Baringer wrote:
simple-error putting you in an sldb-buffer. The backtrace will contain a bunch of extra frames intreduced by the simple-error, but all the restarts and frames are there.
to be precise: the frames and restarts created by the original condition signalled in that thread (ie the condition you're actually interested in) will be there.
-- 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
Marco Baringer mb@bese.it writes:
Attaching a slime-repl to a thread: (bound to a in the slime-list-thread menu) This will interuppt the thread, start a (fore ground) server in it and attach to that server in a new repl buffer.
Hmm.. this requires a bit more of work. I basically broke the support for multiple connections on the Lisp side when I added the control thread stuff. I did this because we can now talk to multiple threads over a single connection (many messages contain a thread id) and thought the code for multiple connections is no longer needed. There are a few global variables and some code will break if there are two parallel connections.
For multiple listeners we need support for multiple (redirected) streams. We could add this to the protocol, e.g., by including stream ids in the messages, or we could re-add support for multiple connections.
Helmut.
On Venerdì, feb 27, 2004, at 18:14 Europe/Rome, Helmut Eller wrote:
For multiple listeners we need support for multiple (redirected) streams. We could add this to the protocol, e.g., by including stream ids in the messages, or we could re-add support for multiple connections.
isn't this only an issue for multi-threaded servers?
-- 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
Marco Baringer mb@bese.it writes:
On Venerdì, feb 27, 2004, at 18:14 Europe/Rome, Helmut Eller wrote:
For multiple listeners we need support for multiple (redirected) streams. We could add this to the protocol, e.g., by including stream ids in the messages, or we could re-add support for multiple connections.
isn't this only an issue for multi-threaded servers?
Not sure I understand the question. Currently slime-thread-attach creates a new connection and implicitly a new control-thread. So it is a multi-threaded server.
Perhaps I just don't understand the intention behind slime-thread-attach. Isn't the goal to create a new repl buffer where the output/input of the specific thread gets inserted?
Helmut.
On Venerdì, feb 27, 2004, at 20:39 Europe/Rome, Helmut Eller wrote:
Not sure I understand the question. Currently slime-thread-attach creates a new connection and implicitly a new control-thread. So it is a multi-threaded server.
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. I want to be able to jump into the thread, examine some special variables, fix what needs to be fixed and then continue.
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.
-- 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
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.
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
-
Helmut Eller -
Marco Baringer