[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Sat, 29 Jul 2006 10:40:20 +0200
Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)
David Kastrup <address@hidden> writes:
> Chong Yidong <address@hidden> writes:
>> David Kastrup <address@hidden> writes:
>>> Since we have the new sit-for implementation, I have a lot of times
>>> when Emacs just pauses in busy waiting for input. This happens
>>> spontaneously. One situation where it happens frequently is when
>>> reading news with gnus.
>> I haven't seen this problem in my usage of gnus.
> It is not just gnus. And it is not easy to see: Emacs gets somewhat
> sluggish, sometimes the cursor blinks quite less than expected, and
> CPU usage goes up, up, up, which is of course mostly noticeable when
> you have power management, and the fans start waking up.
>> It would be helpful if you could be more specific: does the problem
>> happen with the 2006-07-26 change to `read-event'?
> Already before. I have now recompiled Emacs and will see whether this
> changes something.
Update: it still happens. I am working for a while in a web browser,
suddenly the fans engage, the Emacs frame (not even mapped when this
happens) shows a very slow and erratically blinking cursor, and `top'
shows that Emacs is consuming close to 100% of CPU power.
So yes, even an off-screen Emacs sitting idle in some frame suddenly
decides to suck up all CPU power.
>> If so, did it start to happen at that time, or did it already
>> happen after the Lisp-level `sit-for' was implemented?
>> If it only started after the `read-event' change, one possibility
>> is that read_char is getting stuck somewhere before we get to the
>> point where we check if the timeout has elapsed.
>>> This is really a nuisance. The change to sit-for is a fundamental
>>> change to some core mechanism of Emacs, and it is currently
>>> seemingly breaking quite a few things, apart from causing strange
>> That's the story of the Emacs 22 feature freeze.
I can't remember any change as invasive as that without a
correspondingly bad bug it was trying to fix.
David Kastrup, Kriemhildstr. 15, 44793 Bochum