This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 0/7] Implement proposed POSIX _clockwait variants of existing _timedwait functions
On 13/03/2019 18:42, Mike Crowe wrote:
> 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.
Indeed I was using the current practice for pthreads extension, but I if
the idea is to use the same naming for a future POSIX inclusion I think
that guarding with __USE_GNU should be suffice.
>
>>> 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.
I will try to get this upstream as well.
>
>>> 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.
Strictly speaking it depends of the kABI, but afaik from the support ones
only MIPS-n32 actually uses 7 arguments syscalls. I think we can safely
assume all current ABIs support 6 arguments syscalls.
>
> [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.
>