[PATCH] clock_nanosleep(2)

Corinna Vinschen corinna-cygwin@cygwin.com
Wed Aug 3 09:28:00 GMT 2011

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 Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

More information about the Cygwin-patches mailing list