Re: It seems that I find a zle -F full CPU bug

[Peter Stephenson <p.stephenson@xxxxxxxxxxx>]

On Wed, 19 Feb 2014 23:30:52 -0800
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> On Wednesday, February 19, 2014, lilydjwg <lilydjwg@xxxxxxxxx> wrote:
> >
> >
> > I've checked Src/Zle/zle_main.c and see a "for(;;)" loop. That loop will
> > break only when no fds are ready, or the user types something. So,
> > before the user types something and after the watched fd becomes
> > invalid, zsh keeps poll that fd and gets lots of POLLNVAL.
> 
> 
> Although it would be better if zsh did not begin hogging the CPU, it's
> possible for that closed descriptor to be re-opened again (e.g. by a signal
> handler), so unless we are willing to ignore that I'm not sure what to do.
>  I suppose we could drop the fd on the first POLLNVAL for the duration of
> that particular loop, but then reinstate it before restarting the loop
> after the next user input.

That doesn't sound a bad compromise.

Ideally we'd want to make the user aware of the error, but once per user
input, i.e. typically a key press, is probably too often for that.

> I don't think we want to go so far as to make it an error to pass a closed
> fd to zle -F ... and that wouldn't help in this case anyway?

I don't see any real point in testing it before we use it.  I think this
is part of the same problem of how we signal to the user their fd isn't
working without messing up the display.

pws