Re: [PATCH v2 0/6] My attempts[1] to add a variant of pthread_cond_timedwait that would accept

[Mike Crowe <mac at mcrowe dot com>]

On Thursday 09 May 2019 at 10:54:08 +0200, Yann Droneaud wrote:
> Hi,
> 
> Le mardi 07 mai 2019 à 18:50 +0100, Mike Crowe a écrit :
> > a clockid_t parameter led me to propose[2] to The Austin Group the addition
> > of an entire family of functions that accept a clockid_t parameter to
> > indicate the clock that the timespec absolute timeout parameter should be
> > measured against. They responded positively to the request but an
> > implementation is required before the proposal can proceed.
> > 
> > This patch series is the second version of the first part of that
> > implementation in glibc, it contains implementations and tests for
> > four new functions:
> > 
> > int pthread_cond_clockwait(pthread_cond_t *cond, pthread_mutex_t *mutex,
> >                            clockid_t clock, const struct timespec *abstime)
> > 
> > int pthread_rwlock_clockrdlock(pthread_rwlock_t *rwlock, clockid_t clock,
> >                                const struct timespec *abstime)
> > 
> > int pthread_rwlock_clockwrlock(pthread_rwlock_t *rwlock, clockid_t clock,
> >                                const struct timespec *abstime)
> > 
> > int sem_clockwait(sem_t *restrict, clockid_t clock_id, const struct
> >                   timespec *restrict)
> > 
> 
> I'm probably bikeshedding now but should the API be modeled like the
> clock_nanosleep() function:
> 
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_nanosleep.html
> 
>   int clock_nanosleep(clockid_t clock_id,
>                       int flags,
>                       const struct timespec *rqtp,
>                       struct timespec *rmtp);
> 
> Having a flag parameter would allow TIMER_ABSTIME to be used for
> absolute timeout, and 0 for relative timeout, like the already existing
> functions.
> 
> More, having a flag parameter would allow future extensions for the
> API, without the need for a new set of function.
> 
> For relative timeout, being able to retrieve the remaining timeout
> could also help when designing event loop.

I think that this would be better added to
http://austingroupbugs.net/view.php?id=1216 or posted to the Austin Group
mailing list in response to
https://www.mail-archive.com/austin-group-l@opengroup.org/msg03939.html

But,
https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_cond_timedwait.html
(the text of which comes from The Open Group Standard Base Specifications,
Issue 7, 2018 Edition) explains why absolute timeouts are preferred by the
existing timedwait functions.

Thanks.

Mike.