Martin Simmons martin@xanalys.com writes:
The problem might be in SWANK::ENCODE-MESSAGE. I assume that emacs is on the other end of the stream, but if it fails to read fast enough then one of the CL stream functions in SWANK::ENCODE-MESSAGE might block, which will cause the error because this happens inside the WITHOUT-INTERRUPTS.
The intention of WITHOUT-INTERRUPTS is that we don't get a signal half way through send a message to Emacs and then enter the debugger and start a new message. That way we'd garble up the on-the-wire protocol.
However, this is mostly an issue for select()/SERVE-EVENT based communications. In multithreaded (the :SPAWN communication style) it's always the dedicated "control thread" that sends the messages, and if that thread gets a signal and hits the debugger I think you're cactus anyway. So WITHOUT-INTERRUPTS is probably not buying us anything.
The original poster could try hacking swank-lispworks.lisp so that (call-without-interrupts fn) just does (funcall fn) and see if that clears it up. Likewise with the OpenMCL backend.
-Luke