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), pthread_condattr_[gs]etclock(3)


On Thu, 2011-07-21 at 11:35 +0200, Corinna Vinschen wrote:
> On Jul 21 11:21, Corinna Vinschen wrote:
> > No, you're not at all off-base.  Personally I'd prefer to use the native
> > NT timer functions, but that's not important.

No problem, that's something I keep forgetting about.

> > What I'm missing is a way to specify relative vs. absolute timeouts in
> > your above sketch.  I guess we need a flag argument as well.

Working on this last night, I decided to make the timeout a LONGLONG of
100ns units instead, positive for absolute and negative for relative.

> > Other than that, I think we should make sure to create the waitable
> > timer only once on a per-thread base.  Object creation and deletion is
> > usually a time consuming process.  So what we could do is to add a
> > HANDLE "cw_timer" to struct _local_storage in cygtls.h, which gets
> > inited to NULL in _cygtls::init_thread as well as in
> > _cygtls::fixup_after_fork.
> > 
> > Then cancelable_wait with a non-NULL timespec would check for the handle
> > being NULL and create a non-inheritable timer, if so.  All subsequent
> > calls only set (and cancel) the timer.
> > 
> > Does that sound reasonable?
> 
> Btw., if you call NtQueryTimer right before NtCancelTimer, then you get
> the remaining time for free to return to clock_nanosleep.  It would
> be nice if NtQueryTimer would return the remaining time after calling
> NtCancelTimer, but my experiments show that some weird value gets
> returned.  See my attached testcase.  Build with -lntdll.

Thanks, that was the piece I was missing last night.


Yaakov



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