This is the mail archive of the
cygwin-patches
mailing list for the Cygwin project.
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