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

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Thursday, February 20, 2014, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
wrote:

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

Interrupt on a signal is a case where this can happen, it appears.


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

If there is user typeahead this branch is going to read it and return.  If
not then it falls through to one of poll() or select() on the other
descriptors.  So I this appears OK, though it may be delayed more than
other cases in calling the handlers.


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


 Hmm.  It appears that a widget handlers (zle -F -w) will never get
anything but a descriptor number.  Without -w, the handler will get either
the descriptor number or a string describing the error condition (which
means in order to remove itself on an error, the handler has to know out of
band which descriptor it is watching?).  Those error-string values are not
documented.

However ... and again I may be reading this wrong ... I think the outer
test for whether to call the handler at all will skip the handlers for FDs
with error states.  In the HAVE_POLL branch, for example, it first looks
for the POLLIN flags but not for any error flags?  So it will never reach
the set of tests that examine POLLNVAL et al.?

That aside, dropping the invalid descriptors for the select() case is easy,
just change the bitflags.  For the poll() case it's going to be more work
because the fds[] array of structs will have to be rearranged.