win32: make g_cond_wait_until() wait at least until end_time before returning with... 583fb1a397023257ea3d2ee81f88b360007f07a221/head
commit583fb1a397023257ea3d2ee81f88b360007f07a2
authorChristoph Reiter <reiter.christoph@gmail.com>
Thu, 10 May 2018 11:28:49 +0000 (10 13:28 +0200)
committerChristoph Reiter <reiter.christoph@gmail.com>
Sun, 27 May 2018 09:09:29 +0000 (27 11:09 +0200)
treef87947520f93f0c1256b83816d6762151ede22a7
parentab116c31117a8dd141745db0404b63df04577677
win32: make g_cond_wait_until() wait at least until end_time before returning with a timeout. See #1371

The tests in test_async_queue_timed() assume that g_async_queue_timeout_pop()
and in turn g_cond_wait_until() wait at least until end_time
before returning, i.e. calling g_get_monotonic_time() after the timeout should result
in a value equal or larger than the timeout end time.

For the win32 implementation of g_cond_wait_until() this isn't the case which
makes those tests fail.

There are three reasons why the function returns early:

1) The underlying API works with milliseconds and the timeout gets rounded
   down, resulting in a too small timeout value.
2) In case the timeout is too large to be passed to the API it gets limited
   (there is also a bug because it converts INFINITE to milliseconds while
   they already are, but using INFINITE would be wrong as well, as passing
   a large timeout is not the same as blocking forever really)
3) Even with the rounding changed the underlying API still returns a bit early
   sometimes on my machine (relative to g_get_monotonic_time())

This changes the implementation to round up to the next millisecond (fixing 1)
and to wait again in case a timeout occurs but the end time hasn't been
reached yet (fixing 2 and 3).

This makes the test_async_queue_timed() tests pass.

https://bugzilla.gnome.org/show_bug.cgi?id=795569
glib/gthread-win32.c