On Aug 3 04:19, Yaakov (Cygwin/X) wrote: > On Wed, 2011-08-03 at 09:45 +0200, Corinna Vinschen wrote: > > On Aug 3 01:20, Yaakov (Cygwin/X) wrote: > > > On Tue, 2011-08-02 at 17:42 +0200, Corinna Vinschen wrote: > > > > Does that mean the return value from NtQueryTimer is unreliable? > > > > In what way is it wrong? > > > > > > I'm not sure. When I run an STC (attached), it works as expected. In > > > cancelable_wait(), however, it returns the negative system uptime. Is > > > Cygwin doing something to make this occur? > > > > That sounds weird. How should Cygwin influence what an independent OS > > function returns? And you sure it's the system uptime? Wow. > > 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? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
