I can't help but notice that when there are multiple threads, and the debugger is invoked, all threads are halted. For what I'm doing, I'd much prefer that only the thread which caused the error is halted. I see that I could achieve this by removing the (without-scheduling) in debug.lisp, but my question is, how safe is this?
From what I can see, the debugger itself always creates shadowing bindings rather than actually altering its globals, so there won't be race conditions - but there could still be trouble if some other thread modifies a data structure being inspected, or something of the sort. Has the debugger been designed with this sort of use in mind? What issues are likely to come up? Although I expect it will be some time before I have the familiarity with cmucl to hack this stuff myself, I'm willing to at least try to do some coding. As to the desired semantics, the reason I can make it useful is that what I primarily want is to run many applications of one thread each within the same process. Thus there won't be deadlock or livelock while the debugger is running. Obviously, for something like a multithreaded webserver, stopping all threads is the only reasonable behaviour; but that's not the case for me. | Dan Knapp, Knight of the Random Seed | http://brain.mics.net/~dankna/ | ONES WHO DOES NOT HAVE TRIFORCE CAN'T GO IN.
