This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: pthread_cond_timedwait/posix timers
- From: Amos Waterland <apw at us dot ibm dot com>
- To: "H. J. Lu" <hjl at lucon dot org>
- Cc: libc-alpha at sources dot redhat dot com, Xavier Leroy <Xavier dot Leroy at inria dot fr>, Kaz Kylheku <kaz at ashi dot footprints dot net>, Tom Gall <tom_gall at vnet dot ibm dot com>
- Date: Thu, 8 Aug 2002 16:07:34 +0000
- Subject: Re: pthread_cond_timedwait/posix timers
- References: <20020807182824.A31959@kvasir.austin.ibm.com> <20020808120739.A28613@lucon.org>
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