Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

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

Using Fedora 5.0.5 and similar background code from Bart (http://www.zsh.org/mla/users/2014/msg00448.html) I can see the same POLLNVAL high CPU from strace.

Is there any suitable workaround for 5.0.5 ?



On 20/02/14 13:16, lilydjwg wrote:
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.

Messages sorted by: Reverse Date, Date, Thread, Author