Wed Aug 3 10:20:00 GMT 2011
On Aug 3 04:35, Yaakov (Cygwin/X) wrote:
> 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.
Yes, I know. I was just wondering about the reliability factor of
the value returned by NtQueryTimer. Using the absolute value after
the call to NtCancelTimer and subtracting the start time may be more
But, never mind. Your patch looks good to me. Please apply.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
More information about the Cygwin-patches