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

[lilydjwg <lilydjwg@xxxxxxxxx>]

On Thu, Feb 20, 2014 at 09:40:53AM +0000, Peter Stephenson wrote:
> On Wed, 19 Feb 2014 23:30:52 -0800
> Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> > 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.

I think this will work. Or we can just break the loop if all we get from
the poll result is POLLNVAL so that handlers can remove bad fds.

> 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?

Actually there is no closed fd passed to zle -F in my case. It's closed
after that.

> 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.

The handler can know that the fd is closed in case of 'poll': the
handler will get an argument like 'hup' or 'nval'. But it doesn't help
in this case: the handler can uninstall itself, but this only takes
effect after the for loop is done.

-- 
Best regards,
lilydjwg