[PATCH 0/7] Implement proposed POSIX _clockwait variants of existing _timedwait functions

[Mike Crowe]

On Tuesday 05 March 2019 at 09:35:01 -0300, Adhemerval Zanella wrote:
> On 27/02/2019 15:23, Mike Crowe wrote:
> > My attempts[1] to add a variant of pthread_cond_timedwait that would accept
> > 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 first part of that implementation in glibc, it
> > contains 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)
> > 
> > These are implemented by replacing the underlying equivalent _timed
> > functions with ones that accept a clockid_t parameter, and then
> > implementing the existing _timed functions by passing CLOCK_REALTIME to the
> > new implementation. This requires clockid_t parameters to be added to the
> > underlying futex-internal and lowlevellock-futex functions.
> 
> I am not sure about how to name a new API in this specific case where
> the idea is to use as a reference one for POSIX inclusion.  MY understanding 
> is we still should use a non-portable name scheme with _np suffix and whence
> it is de factor accepted by POSIX we can just alias to the standard
> names. Also if it is done before the release I think we can avoid exporting 
> the _np naming scheme.

Well, non-POSIX functions are added all over glibc without _np extensions.
:) It seems that the convention is used only for pthreads. I can rework the
patches to use the _np extension if required, but I'd hoped that __USE_GNU
was sufficient protection. Perhaps we should see what Joseph and others
think.

> > pthread_mutex_clocklock is not yet implemented because doing so requires a
> > version of __lll_timedlock_wait that supports both CLOCK_MONOTONIC and
> > CLOCK_REALTIME. This function is currently architecture specific. I plan to
> > work on that next, if these changes are considered acceptable.
> 
> About that I think we can work towards once my lowlevellock.S cleanup
> is accepted [4]. Once __lll_timedlock_wait is implemented in generic
> way it would be much more easier to add such extension.
> 
> [1] https://sourceware.org/ml/libc-alpha/2019-02/msg00569.html

That's great. I'll rebase my changes on top of that one before tackling
pthread_mutex_clocklock.

> > The mq_clockreceive and mq_clocksend functions corresponding to
> > mq_timedreceive and mq_timedsend require kernel changes before they can be
> > implemented in glibc.
> 
> Should we add them as ENOSYS as generic stubs in this version?
> Because it seems the kernel work required would be just add a new
> syscall on ipc/mqueue.c to receive a clock_id since 
> schedule_hrtimeout_range_clock already handle CLOCK_MONOTONIC
> (and it luckily fits on 6 argument syscall limit).

If the six argument limit is universal then that will be very helpful. I'd
previously (apparently incorrectly) scared myself into believing that the
functions were already at the limit. I shall dig some more, but these
functions are currently at the bottom of the list.

[snip stuff about errors for clocks that I have no strong feelings about]

> > A number of tests have been updated to use struct timespec rather than
> > struct timeval so that they can call clock_gettime(CLOCK_MONOTONIC) rather
> > then gettimeofday. To make this easier I created the support/timespec.h
> > header file to contain functions to add and subtract timespec structures
> > borrowed from sysdeps/pthread/posix-timer.h. There's probably a better
> > place for these, but I don't know where that might be.
> 
> I think you forgot to update this part since you seemed to had chose
> to use support/timespec.h instead.

Indeed.

Thanks for all your comments.

Mike.