GNU bug report logs - #22976
24.5; setting unread-command-events to non cons puts emacs in 100% CPU use

Previous Next

Full log

Message #23 received at 22976 <at> debbugs.gnu.org (full text, mbox):

From: Eyal Lotem <eyal.lotem <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Andreas Schwab <schwab <at> suse.de>, 22976 <at> debbugs.gnu.org
Subject: Re: bug#22976: 24.5; setting unread-command-events to non cons puts
 emacs in 100% CPU use
Date: Thu, 10 Mar 2016 14:40:24 +0200

[Message part 1 (text/plain, inline)]

On Thu, Mar 10, 2016 at 12:39 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Date: Thu, 10 Mar 2016 12:34:08 +0200
> > From: Eyal Lotem <eyal.lotem <at> gmail.com>
> > Cc: Andreas Schwab <schwab <at> suse.de>, 22976 <at> debbugs.gnu.org
> >
> > It can be set to any value at all, unfortunately.
>
> That's not what I asked.  I asked whether non-nil, non-cons values
> have any meaning in unread-command-events.
>

Don't think they do. They are an error.

>
> > The problem now is that non-cons/non-nil values are ignored.
> >
> > The loop to repeatedly thinks there's input so it consumes 100% cpu,
> each iteration seeing that it isn't a cons
> > cell, so there's "nothing to do".
>
> Exactly.  So these values aren't ignored, they create an illusion that
> some input is available.  I was thinking about ignoring them entirely,
> i.e. treating such values as nil (and maybe even silently replacing
> them with nil).
>

Ah, sorry I misunderstood originally!

That sounds good to me (though it would be slightly better to warn about it
somewhere, IMO)



>
> The question is: would that kind of change break something?
>

I think most scenarios it would break would be ones that currently consume
100% cpu. So besides scenarios like https://xkcd.com/1172/ it is unlikely :)


-- 
Eyal

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.