[slime-devel] Slime and sbcl, minor problems.

[Luke Gorrie]

Daniel Barlow <dan at 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