Peter Seibel peter@javamonkey.com writes:
Luke Gorrie luke@bluetail.com writes:
Peter Seibel peter@javamonkey.com writes:
So when I use C-c C-c (slime-interrupt) to try to interrupt a long-running computation in SLIME it sometimes takes a really long time (order 10-60 seconds) before the debugger pops up.
When we use the threads-based :SPAWN communication style we don't issue any interrupt/signal, we just send a "please interrupt yourself" message down the socket and wait for the reader-thread to process it. This means that responsiveness is in the hands of Lisp's thread scheduler. With CMUCL cooperative threads this is quite unresponsive and possibly it's the same thing with ACL too.
There may be a better way to handle this. Certainly I prefer :SIGIO to :SPAWN with CMUCL.
So Allegro has a process-priority that could be set. Perhaps the reader-thread should be set to high priority?
Okay, I'm not convinced that it's the Allegro scheduler. Top shows me that emacs is chewing CPU while I'm waiting. I think this lack of responsiveness is actually the same as the large-output problem--I think emacs is spending a ton of time chewing on the stuff Lisp sends back, masticating it into the proper form for an SLDB buffer. (I'm interrupting something which has function calls with very large lists of strings as arguments.) Ironically, I'll never see the output it's spending so much time preparing since I'm just going to invoke the ABORT restart as soon as I get to the debugger. Note, I haven't actually verified that this is what's happening but when I get a chance I'll look into it.
-Peter