Daniel Barlow dan@telent.net writes:
I'm guessing that Slime is not going to like it if multiple requests all cause errors and attempt to start the debugger in quick succession. Even if it does or can be made to, I'm unsure that I'd want to use it that way, so some form of locking in the debugger hook would probably be a good idea.
Are you running this off SERVE-EVENT or with threads?
The sldb-loop does blocking reads from Emacs, so in a single-threaded setup there is no SERVE-EVENT dispatching during debugging -- the server would freeze until sldb returns. So, on the bright side, there shouldn't be any race conditions :-)
Threads aren't a solved problem in SLIME yet, but if you're planning to debug a multithreaded webserver then now is the time to solve it. I suspect it would be sufficient to have a global lock on the SLIME connection, and to hold that lock throughout debugging - so SLIME is only passed between threads when the connection is idle (as in slime-idle-state).
This will be good beyond Araneida. Now that we've taken over the REPL, it makes sense for us take over standard-IO, *debugger-hook*, etc, all the time Emacs is connected, not just during explicit requests. At least as an option.
Beyond a general lack of faith in the layers on layers of stuff that this involves (this might just be my own problem, I'm a software Luddite), I'm still not sure how this would work in the presence of foreign code, which doesn't have Lisp streams to print to, just file descriptors. i think output from that is still going to end up in *inferior-lisp*
But *inferior-lisp* is under our power - all roads lead to Emacs :-)
You could be right - we can explore this stuff afterwards.
Cheers, Luke