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