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

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

[ > workers ]

On Thursday, February 20, 2014, lilydjwg <lilydjwg@xxxxxxxxx> 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:
> > >  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.


Hmm ... looking at the loop, there is already some provision for this.  If
poll() [or select()] returns -1, we discard all the handler FDs etc. and
repeat with just the SHTTY FD.  I wonder if the situation that code is
meant to handle is even possible.

If we're really trying to avoid pathologically bad behavior, we can't rely
on the handler to remove the descriptor.

This is going to require more #ifdef's to examine fds[] in the poll() case
and the bits in errfds in the select() case.

Aside:  Am I misreading the code, or is it the case that the (HAVE_TIO &&
sun) #ifdef branch does not support zle -F ?


> The handler can know that the fd is closed in case of 'poll': the
> handler will get an argument like 'hup' or 'nval'.


I don't think the handler ever gets anything but a file descriptor number?