This is the mail archive of the cygwin-patches mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] clock_nanosleep(2)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]