[slime-devel] Re: Partial multiprocessing support, take 2

[Peter Seibel]

Luke Gorrie <luke at 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 at javamonkey.com

         Lisp is the red pill. -- John Fraser, comp.lang.lisp