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. I've also noticed that if I do something that generates an error that will contain a lot of output (such as saying (boundp *y*) instead of (boundp '*y*) when *y* is list of several thousand standard-objects) then it also takes a really long time for the debugger to come up. I'm running Allegro 6.2 on GNU/Linux. Haven't had a chance to try this out in other Lisps but thought I'd throw it out there in case anyone has seen a similar thing or has any ideas how to speed things up.
-Peter
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.
I've also noticed that if I do something that generates an error that will contain a lot of output (such as saying (boundp *y*) instead of (boundp '*y*) when *y* is list of several thousand standard-objects) then it also takes a really long time for the debugger to come up. I'm running Allegro 6.2 on GNU/Linux.
I see this too when the printed representation is big (e.g. a megabyte). With ACL both Lisp and Emacs chew CPU, with CMUCL it's just Emacs.
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?
-Peter
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
-
Luke Gorrie -
Peter Seibel