[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lib/poll.c bug?
From: |
Erik Faye-Lund |
Subject: |
Re: lib/poll.c bug? |
Date: |
Thu, 30 Jun 2011 20:40:49 +0200 |
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.