On Sat, 24 Feb 2007, Peter Graves wrote:
> Firstly, the Ctrl-C handler is inherently unsafe, since it uses JNI to
> install a signal handler which calls back into Java when you press
> Ctrl-C. It mostly works, and of course when it does work it's very
> useful, but it also crashes Java on occasion; it's not a perfect
> More specifically, I think what's happening when "nothing happens" is
> that the Ctrl-C was noticed by the handler, the Java callback was
> called, which eventually calls BREAK, but since you're doing this as
> the very first thing in a fresh Lisp, a lot of the INVOKE-DEBUGGER
> machinery (such as WITH-STANDARD-IO-SYNTAX) needs to be autoloaded
> before the debugger message and prompt can be displayed. The second
> (and third) Ctrl-C interrupts this autoloading process, and autoloading
> is very likely not safe to interrupt in this way.
> Another problem is that you seem to be running on a fairly slow machine
> (low-level initialization takes 9 seconds), which means all of the
> above takes longer, and you're more likely to hit Ctrl-C again. On a
> fast machine, there really isn't very much time after the first Ctrl-C
> before the debugger prompt appears, so you'd be less likely to hit it
Out of curiosity, I left ABCL alone for a few hours after starting
(loop) and hitting Ctrl-C once. Still no sign of the debugger
message. Now my machine is indeed very slow, but not _that_ slow :-)
It's as if the first Ctrl-C got buffered (meaning only that it doesn't
get through until something (another Ctrl-C) happens). If I hit Return
or Space before Ctrl-C, then I do get the debugger message imediately.
Though even then, chosing the "Return to toplevel" restart leaves ABCL
But what you wrote above about the inherent unsafety of the Ctrl-C
handler is very convincing. So this issue (if it is one) shouldn't
hold back the release.
> Finally, there's a new mechanism which I recommend instead of the Ctrl-
> C handler if you're using slime-for-emacs and the swank stuff is
> running in its own thread: just have that thread call EXT:INTERRUPT-
> LISP when you press the key chord mapped to SLIME-INTERRUPT.
> EXT:INTERRUPT-LISP does exactly what the Ctrl-C handler's signal
> handler does, but without passing through JNI-land, which makes it
> somewhat more reliable. As a side benefit, EXT:INTERRUPT-LISP is also
> available on Windows, which otherwise would need someone to write a
> Windows-specific version of the aforementioned JNI code.
> The EXT:INTERRUPT-LISP approach is currently used in slime-for-j (where
> SLIME-INTERRUPT is mapped by default to Ctrl Alt B), if you have a very
> recent CVS version of j and ABCL.
> There might still be a pregnant pause on a slow machinge after Ctrl-
> Alt-B if stuff needs to be autoloaded, but the pause will probably be
> shorter since loading slime forces more stuff to be loaded to begin
> [There might still be a fixable bug or two in this area. Autoloading
> could possibly be made safer, and EXT:INTERRUPT-LISP could possibly be
> made smarter about which thread to interrupt, if many are running. I
> don't plan to look at these issues before releasing 0.0.10, however,
> in order to get the release done sooner rather than later.]
In theory, slime-for-emacs uses EXT:INTERRUPT-THREAD for this purpose.
In practice, it doesn't work... so it's good to know there's an
alternative. (I should add that "doesn't work" refers to
slime-interrupt as implemented using EXT:INTERRUPT-THREAD, not
EXT:INTERRUPT-THREAD itself. There's significant bit-rotting in
slime-for-emacs, and slime-interrupt may be one of its victims.)