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