Re: lib/poll.c bug?

[Erik Faye-Lund]

On Thu, Jun 30, 2011 at 8:40 PM, Erik Faye-Lund <address@hidden> wrote:
> On Thu, Jun 30, 2011 at 7:51 PM, Eric Blake <address@hidden> wrote:
>> On 06/29/2011 11:31 AM, Erik Faye-Lund wrote:
>>> POSIX says the following about poll "A value of 0 indicates that the
>>> call timed out and no file descriptors have been selected.". My
>>> interpretation is that a return value of 0 would be illegal when
>>> timeout = -1.
>>>
>>> But when I call poll(..., -1), it seems 0 is returned under some
>>> conditions. Looking through the code, it seems that there isn't any
>>> efforts to enforce this paragraph; perhaps the included patch is
>>> appropriate?
>>>
>>> This problem currently affects a feature-branch I have against Git for
>>> Windows, where this cause a program not to consume input because it
>>> assumes that poll(..., -1) cannot return 0. The patch fixes it for me.
>>
>> I think there's a bigger problem here, which is that there is no way to
>> poll on pipes without busy-waiting, at least not with our current poll
>> replacement code.  Your patch would turn poll into a 100% cpu hog in the
>> cases where it is now returning 0.
>
> Good point. But this problem could be offset by adding a Sleep(0) (or
> even SwitchToThread()) right before the goto, no?
>
> Without proper kernel-level support for poll, we probably can't have a
> poll on Windows that suspend the thread until an event happens; we'll
> have to accept a bit of polling. But I believe that looking and
> quacking like POSIX is better than doing something the standard says
> shouldn't happen. Wasting CPU cycles is IMO better than returning 0 in
> this case (but perhaps I'm biased as I've been burned by this
> behavior). Yielding the thread and/or sleeping a bit on retry might be
> a better compromise, though.
>

Ping? Should I re-post the patch with SwitchToThread() squashed in?