[slime-devel] Re: Really slow to interrupt in Allegro 6.2

[Peter Seibel]

Peter Seibel <peter at javamonkey.com> writes:

> Luke Gorrie <luke at bluetail.com> writes:
>
>> Peter Seibel <peter at 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

-- 
Peter Seibel                                      peter at javamonkey.com

         Lisp is the red pill. -- John Fraser, comp.lang.lisp