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

[Yann Droneaud <ydroneaud at opteya dot com>]

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.

Regards.

-- 
Yann Droneaud
OPTEYA