Re: [PATCH] poll: wait until timeout on pipes (win32)

[Eli Zaretskii]

> Date: Wed, 10 Sep 2014 22:17:28 +0000
> From: Edward Thomson <address@hidden>
> 
> I'm very interested in seeing the poll(2) compatibility function wait
> until the timeout has elapsed before returning on win32.  The manual
> indicates that "under Windows, when passing a pipe, Gnulib's poll
> replacement might return 0 even before the timeout has passed."
> 
> Callers expecting poll(2) to honor the timeout may devolve into
> pathological behavior when this expectation is violated.  For example,
> git uses poll's timeout to send a keep-alive packet to the remote
> socket:
> 
> https://github.com/git/git/blob/master/upload-pack.c#L170 and
> https://github.com/git/git/blob/master/upload-pack.c#L234

Are you using the latest gnulib?  A similar problem in 'socket' was
fixed about 3 months ago (see commit aaaf546); since 'poll' calls
'select', perhaps that fix also solves your problems in 'poll'?

In case the fix in 'select' is not enough, and you still need the
changes in 'poll', allow me one comment on your patch:

> GetTickCount is used as it is efficient, stable and monotonically
> increasing.  (Neither GetSystemTime nor QueryPerformanceCounter are.)

I believe you alluded to the fact that GetTickCount is not affected by
system clock adjustments.  That is true, but it is not strictly
monotonically increasing: it wraps around after 49.7 days.  From the
MSDN documentation at
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724408%28v=vs.85%29.aspx:

 ======================================================================
  GetTickCount function

  Retrieves the number of milliseconds that have elapsed since the
  system was started, up to 49.7 days.
 ======================================================================

This function returns an unsigned 32-bit value, and it counts since
the OS was started.  If your program runs close to the 49.7 day
boundary, you will see the wrap around through zero, and your test
against 'start' will then fail, because DWORD is an unsigned data
type.

For that reason, I suggest to use 'clock' instead.  It also returns a
32-bit value, but its advantage is that it counts since the program
start time, so the danger of wrap-around is much lower.

An even better possibility is to use GetSystemTimeAsFileTime, which
returns a 64-bit value representing the UTC time since Jan 1, 1601,
with 100-nsec resolution.  This one is indeed monotonically
increasing, but doing arithmetics on it is a bit more complicated
(though certainly not rocket science).

Thanks.