Old pthreads-win32 used GetSystemTimeAsFileTime (UTC) for *_timedwait. mingw-w64's winpthreads also uses GetSystemTimeAsFileTime (UTC) for clock_gettime. However, mingw-w64's *_timedwait compares the abstime with the local (not UTC) time retrieved by _ftime. This seems to me to be a serious bug in *_timedwait.
Furthermore, I notice the code is turning the abstime into a relative time. If this is interpreted by the OS in a monotonic way, *_timedwait really should fail unless the clock is specified as CLOCK_MONOTONIC.
hmm, yes there might be something fishy. Could you provide me some documentation that timedwait API should be gm-time?
The relevant specifications are:
http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_cond_timedwait.html
http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_cond_timedwait.html
http://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_getres.html
Observe pthread_cond_timedwait's "Timed Condition Wait" example demonstrates a timer equivalent to CLOCK_REALTIME, and clock_gettime defines CLOCK_REALTIME as seconds since the Epoch.
Fixed on master at 1010ba215580ef8fc68b5f985b0e6bcf87305202