Re: [PATCH v3 2/6] nptl: Add POSIX-proposed sem_clockwait

[Florian Weimer <fweimer at redhat dot com>]

* Adhemerval Zanella:

> On 25/06/2019 18:39, Florian Weimer wrote:
>> * Mike Crowe:
>> 
>>> On Tuesday 25 June 2019 at 20:06:53 +0200, Florian Weimer wrote:
>>>> * Mike Crowe:
>>>>
>>>>> On Wednesday 05 June 2019 at 18:07:18 -0300, Adhemerval Zanella wrote:
>>>>>> On 27/05/2019 17:03, Mike Crowe wrote:
>>>>>>> Add:
>>>>>>>
>>>>>>>  int sem_clockwait (sem_t *sem, clockid_t clock, const struct timespec *abstime)
>>>>>>>
>>>>>>> which behaves just like sem_timedwait, but measures abstime against the
>>>>>>> specified clock. Currently supports CLOCK_REALTIME and CLOCK_MONOTONIC and
>>>>>>> sets errno == EINVAL if any other clock is specified.
>>>>>>
>>>>>> For non-POSIX definition we will need to first export it as a GNU extension
>>>>>> with a possible non-reserved name and later, when it is included on the 
>>>>>> standard, to add an alias to the expected name.  
>>>>>>
>>>>>> The usual naming scheme is to append the _np suffix (non-portable) on 
>>>>>> implementation, similar to recent posix_spawn file action extensions.
>>>>>> In this case it would be sem_clockwait_np.
>>>>
>>>>> I thought we went through this before[1] and agreed that the _np suffix wasn't
>>>>> necessary in this case. However, I couldn't find a reply to Florian
>>>>> agreeing to that.
>>>>
>>>> Upon second thought, I agree with Adhemerval here.  We should use a
>>>> function with the _np suffix, otherwise we'll be in a world of pain if
>>>> something else is standardized.
>>>
>>> Well, the plan is to standardise this[1] and The Austin Group are the ones
>>> who decided on the names, but there needs to be an implementation before
>>> that can happen. Presumably that implementation can have _np suffixes in
>>> the short term though.
>>>
>>> I shall apply some sed to the patch series and repost.
>> 
>> Sorry, I see that we don't use _np for the other functions.
>> I'm confused now. 8-(
>> 
>> Adhemerval, is there value in keeping this consistent?  Have these
>> functions progressed to different stages in the POSIX process?
>
> My understanding of Austin proposal [1] (Mike can correct me) is naming is
> settled and Android will also probably follow the same naming scheme. However, 
> since Austin Group does not really propose newer interfaces, they
> required a actual implementation to move forward.
>
> Joseph also added sometime ago on IRC that we should add the symbols with 
> the expected naming, but keep in mind there might be future incompatibilities 
> requiring symbol versioning.
>
> [1] http://austingroupbugs.net/view.php?id=1216

I'm still puzzled what's different compared to
posix_spawn_file_actions_addfchdir_np or pthread_rwlock_clockrdlock.
Are they at different stages of the POSIX process?

Thanks,
Florian