This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc 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: pthread_cond_timedwait/posix timers


On Thu, Aug 08, 2002 at 12:07:39PM -0700, H. J. Lu wrote:
> On Wed, Aug 07, 2002 at 06:28:24PM +0000, Amos Waterland wrote:
> > There are some problems with the POSIX timer and condition wait
> > implementation in glibc.  I am very interested in fixing them, but think
> > that it would be best to have a discussion over the list first.
> 
> FYI, those are academic to me. I have a real issue to solve:

Thanks for your reply.

> http://sources.redhat.com/ml/libc-alpha/2002-02/msg00057.html
> 
> That is why I added the relative timeout interface. In my case, I
> really don't care how precise it is. But it should never wait for
> a few years unless it is really intended :-).

Agreed.  But the standard implies that pthread_cond_timedwait() *should*
wait for 20 years if it is based upon CLOCK_REALTIME.

Having interval timers expire at incorrect times is not really just an
academic issue.

The reason I wanted to ask people on the list is that I don't see a
clean way to solve either problem in userspace.  We could make
pthread_cond_timedwait() respect CLOCK_REALTIME with a ugly nanosleep()
poll approach, and could use the solution for relative timers I
mentioned in my previous email, but both will have performance/ugliness
problems.

As mentioned by Drepper, Azinger, Bernecky, and Kylheku, probably the
only way to fix these problems correctly is to have a real
clock_nanosleep() provided by the kernel.  Unless anybody has a bright
idea, I am going to defer further work on these issues until the
high-res-timers go into the kernel.

Amos Waterland


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