On Thu, Jun 30, 2011 at 8:40 PM, Erik Faye-Lund <kusmab...@gmail.com> wrote: > 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. >
Ping? Should I re-post the patch with SwitchToThread() squashed in?
