bug-gnulib
[Top][All Lists]
Advanced

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]