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 Jul 20 04:50, Yaakov (Cygwin/X) wrote:
> On Wed, 2011-07-20 at 04:16 -0500, Yaakov (Cygwin/X) wrote:
> > On Wed, 2011-07-20 at 09:56 +0200, Corinna Vinschen wrote:
> > > This doesn't look right.  In contrast to nanosleep, clock_nanosleep
> > > is not subsumed under the _POSIX_TIMERS option.  In fact it's the only
> > > function under the _POSIX_CLOCK_SELECTION option.
> > 
> > I did some searching, and there are actually two more:
> > 
> > http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_condattr_getclock.html

As long as it's not implemented, I don't see a problem.

> > 
> > The behaviour of the following functions are also affected by this
> > option:
> > 
> > http://pubs.opengroup.org/onlinepubs/009695399/functions/clock_getres.html
> > http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_cond_wait.html
> > 
> > (It should be noted that the Clock Selection option was merged into the
> > Base with POSIX.1-2008.)
> > 
> > How should we proceed now?
> 
> Actually, no need to panic, I took a closer look at this, and it's not
> all that hard at all, so I'll go ahead and implement
> pthread_condattr_[gs]etclock() as well.  Just give me a day or two to
> get it done.  In the meantime, I'll proceed with the revised newlib
> patch.

Thanks.

The only problem I see is the fact that a call to clock_settime
influences calls to clock_nanosleep with absolute timeouts(*).

The problem is that we convert absolute timeouts to relative timeouts
and then use the timeout facility of the WFMO function to handle the
timeout for us.  IMO this is neither very reliable, nor is it elegant.

So, here's the question.  Shouldn't we better use waitable timers
to implement this sort of stuff?  Waitable timers are pretty easy to
use, they support relative and absolute timeouts with an accuracy of 100
ns in the API and a real accuracy which only depends on the underlying
HW, and they are especially not subject to the 49.7 days overflow
problem.


Corinna


(*) Does it also influence pthread_cond_timedwait?  This information seems
    to be missing in SUSv4.

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