Ahoy,
I checked in some very basic multiprocessing support. It works with SBCL and CMUCL and it should be easy to port.
Threads automatically create new connections on-demand and can all talk to Emacs at the same time. There is no flow-control, so if 20 threads hit the debugger at once then you can expect 20 layers of SLDB buffers to pop up :-). There is no real policy for standard I/O streams or for interrupting yet -- "it does what it does".
There is some commentary in swank.lisp about how multiple-connections work from the Lisp side (short version: one per thread created on demand). I also changed (shrunk) the multiprocessing interface in swank-backend, it should be implementable in 20 lines or so and all that's needed for a port.
For people already using threads it should be a great improvement. For people not using threads it shouldn't break anything.
There's a caveat for SBCL: spawning threads from SLIME (e.g. the REPL) doesn't work properly. When you spawn a thread in SBCL it inherits the dynamic bindings from its parent, but it seems to get some things that were supposed to be thread-specific/temporary in the bargain. I'll ask Dan about this stuff when he gets back online.
BTW, there is a job opening for a threads user-interface designer/hacker. Helmut and I aren't threads users, so we're not the guys to do this stuff. It would be better for some threads hacker(s) to muck around and figure out a good UI, and we can help with the infrastructure (which is hopefully mostly there now).
Cheers, Luke
Luke Gorrie luke@bluetail.com writes:
I checked in some very basic multiprocessing support. It works with SBCL and CMUCL and it should be easy to port.
I forgot to mention - if you want to use MP, you should add this to your .emacs:
(setq slime-multiprocessing t) (setq slime-global-debugger-hook t)
The first one makes sure it gets initialized, the second globally installs the SLIME *debugger-hook* so all threads will use Emacs for debugging.
-Luke
Luke Gorrie luke@bluetail.com writes:
BTW, there is a job opening for a threads user-interface designer/hacker. Helmut and I aren't threads users, so we're not the guys to do this stuff. It would be better for some threads hacker(s) to muck around and figure out a good UI, and we can help with the infrastructure (which is hopefully mostly there now).
How about a threads user-interface kibitzer?
You may have done this already but it seems like a reasonable solution to the 20 threads drop into the debugger at the same time is to have a *slime-threads* buffer that is like a dired window for all the threads that have assocated emacs buffers. This buffer can be used to show what state different threads are in (waiting at the REPL, running in the background, or in the debugger) and allow the user to easily get to the right buffer to interact with a specific thread. With some ability to sort the listing by various criteria (thread name, state, etc.) this would make things pretty managable. Folks doing hardcore debugging on a threaded app might simply open this buffer in a new window and leave it visible somewhere so as new threads drop into the debugger and their state changes it is obvious. Then the actual *sldb* buffers can be opened in the background.
Sorry if this is all obvious or alredy implemented. (Haven't had a chance to play around with any of the multithreading stuff in SLIME yet.)
-Peter
Peter Seibel peter@javamonkey.com writes:
You may have done this already but it seems like a reasonable solution to the 20 threads drop into the debugger at the same time is to have a *slime-threads* buffer that is like a dired window for all the threads that have assocated emacs buffers.
*nod*, I had that in the previous impl. I'll add support again soon and try to supe it up a bit, and we can see how it feels.
-Luke
-
Luke Gorrie -
Peter Seibel