[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.


Yaakov




More information about the Cygwin-patches mailing list