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 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.


Yaakov



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