> Date: Wed, 10 Sep 2014 22:17:28 +0000 > From: Edward Thomson <ethom...@edwardthomson.com> > > 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.
