[PATCH] clock_nanosleep(2)

Yaakov (Cygwin/X) yselkowitz@users.sourceforge.net
Wed Aug 3 09:35:00 GMT 2011

On Wed, 2011-08-03 at 11:27 +0200, Corinna Vinschen wrote:
> On Aug  3 04:19, Yaakov (Cygwin/X) wrote:
> > Never mind, I figured it out.  The difference is the timeout to
> > WaitFor*Object*(); my STC doesn't allow the timer to finish, but
> > cancelable_wait() does with the INFINITE timeout.  If there is time
> > remaining, as in the STC, then TIMER_BASIC_INFORMATION.TimeRemaining
> > contains just that (as a positive).  If the timer has signalled, then
> > instead of zero, it appears to provide when it was signalled (system
> > uptime, as a negative).
> This is cool.  Does it match the tickcount as returned by
> hires_ms::timeGetTime_ns()?  If so, it sounds like the return value from
> NtQueryTimer *after* the NtCancelTimer call would be usable and probably
> more reliable than calling NtQueryTimer first, then NtCancelTimer.
> What do you think?

The only thing that uses the remaining time is nanosleep(), which uses a
relative timeout.  Same thing will go for clock_nanosleep(): per POSIX,
rmtp is only returned if TIMER_ABSTIME is not set.  If we only care
about relative remainders, then calling NtQueryTimer first is the
simplest way to go, as in my patch.


More information about the Cygwin-patches mailing list