On Thu, Jun 30, 2011 at 7:51 PM, Eric Blake <ebl...@redhat.com> 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.
