[musl] implement pthread_cond_clockwait?

[musl] implement pthread_cond_clockwait?

[Jₑₙₛ Gustedt]

Hi,
Posix 2024 now has this function and it is mandatory. It seems that it
is not very difficult to implement in musl. Would it make sense to
send a patch?

Thanks
Jₑₙₛ

-- 
:: ICube :::::::::::::::::::::::::::::: deputy director ::
:: Université de Strasbourg :::::::::::::::::::::: ICPS ::
:: INRIA antenne de Strasbourg :::::::::::::::::: Camus ::
:: INRIA PIQ program Strasbourg :::::::::: piq.inria.fr ::
:: :::::::::::::::::::::::::::::::::::: ☎ +33 368854536 ::
:: https://icube-icps.unistra.fr/index.php/Jens_Gustedt ::

Re: [musl] implement pthread_cond_clockwait?

[Rich Felker]

On Fri, Mar 21, 2025 at 11:05:27AM +0100, Jₑₙₛ Gustedt wrote:
> Hi,
> Posix 2024 now has this function and it is mandatory. It seems that it
> is not very difficult to implement in musl. Would it make sense to
> send a patch?

I think so, but there might already be one. IIRC there are several
other explicit-clock functions to be added. I was originally hesitant
before they were standard because it's an extra level of call that
can't be a tail-call on many archs (because extra argument), but now
it's necessary to add them anyway. If the cost matters it could
probably be alleviated with an explicit trylock first, but we already
do the equivalent for normal-type mutexes which are the main ones
whose performance matters.

Rich

Re: [musl] implement pthread_cond_clockwait?

[Jₑₙₛ Gustedt]

Hello Rich,

on Fri, 21 Mar 2025 08:50:08 -0400 you (Rich Felker <dalias@libc.org>)
wrote:

> On Fri, Mar 21, 2025 at 11:05:27AM +0100, Jₑₙₛ Gustedt wrote:
> > Hi,
> > Posix 2024 now has this function and it is mandatory. It seems that
> > it is not very difficult to implement in musl. Would it make sense
> > to send a patch?  
> 
> I think so, but there might already be one.

I did not find easily on the mailing list. Where should I look
otherwise?

> IIRC there are several other explicit-clock functions to be added.

Yes, seems to be for all relevant lock structures that have interfaces
with timing.

> I was originally hesitant before they were standard because it's an
> extra level of call that can't be a tail-call on many archs (because
> extra argument), but now it's necessary to add them anyway. If the
> cost matters it could probably be alleviated with an explicit
> trylock first, but we already do the equivalent for normal-type
> mutexes which are the main ones whose performance matters.

`pthread_cond_t` is especially simple, because there is already
internal state (coming from `pthread_condattr_setclock`) that is
loaded into a local variable. So basically all is already in place,
we'd just have to split the interface a bit.

For the possible performance impact, at least for that one it would
only be potential reordering of parameters. They had the brilliant
idea of putting this new argument as the one before last. So there
would probably be an overhead of one or two instructions ;-)

So I would see this to move the current implementation of
`pthread_cond_timedwait` to a new `__pthread_cond_clockwait` by
lifting the local clock parameter into the parameters. Then
`pthread_cond_timedwait` and `pthread_cond_clockwait` could be simple
wrappers to that.

Jₑₙₛ

-- 
:: ICube :::::::::::::::::::::::::::::: deputy director ::
:: Université de Strasbourg :::::::::::::::::::::: ICPS ::
:: INRIA antenne de Strasbourg :::::::::::::::::: Camus ::
:: INRIA PIQ program Strasbourg :::::::::: piq.inria.fr ::
:: :::::::::::::::::::::::::::::::::::: ☎ +33 368854536 ::
:: https://icube-icps.unistra.fr/index.php/Jens_Gustedt ::

Re: [musl] implement pthread_cond_clockwait?

[Leah Neukirchen]

Jₑₙₛ Gustedt <jens.gustedt@inria.fr> writes:

> Hello Rich,
>
> on Fri, 21 Mar 2025 08:50:08 -0400 you (Rich Felker <dalias@libc.org>)
> wrote:
>
>> On Fri, Mar 21, 2025 at 11:05:27AM +0100, Jₑₙₛ Gustedt wrote:
>> > Hi,
>> > Posix 2024 now has this function and it is mandatory. It seems that
>> > it is not very difficult to implement in musl. Would it make sense
>> > to send a patch?  
>> 
>> I think so, but there might already be one.
>
> I did not find easily on the mailing list. Where should I look
> otherwise?

Shameless plug for my mailing list archive:
https://inbox.vuxu.org/musl/?q=pthread_cond_clockwait

-- 
Leah Neukirchen  <leah@vuxu.org>  https://leahneukirchen.org/

Re: [musl] implement pthread_cond_clockwait?

[Jₑₙₛ Gustedt]

Hello Leah,

on Fri, 21 Mar 2025 15:28:28 +0100 you (Leah Neukirchen
<leah@vuxu.org>) wrote:

> Jₑₙₛ Gustedt <jens.gustedt@inria.fr> writes:
> 
> > Hello Rich,
> >
> > on Fri, 21 Mar 2025 08:50:08 -0400 you (Rich Felker
> > <dalias@libc.org>) wrote:
> >  
> >> On Fri, Mar 21, 2025 at 11:05:27AM +0100, Jₑₙₛ Gustedt wrote:  
>  [...]  
> >> 
> >> I think so, but there might already be one.  
> >
> > I did not find easily on the mailing list. Where should I look
> > otherwise?  
> 
> Shameless plug for my mailing list archive:
> https://inbox.vuxu.org/musl/?q=pthread_cond_clockwait

ah, thanks!

so basically, yes, the patch is there, but I didn't find it because
there is a supplementary "d" in the name of the function :-((

At the time that was proposed, things didn't move forward because
there were extensions to the C interfaces proposed in the same batch
as well. Also the POSIX functions were not yet part of the standard.

So should I (or Yonggang if they want to) separate this out from the
series, correct the obvious error, and rebase on current musl?

Jₑₙₛ

-- 
:: ICube :::::::::::::::::::::::::::::: deputy director ::
:: Université de Strasbourg :::::::::::::::::::::: ICPS ::
:: INRIA antenne de Strasbourg :::::::::::::::::: Camus ::
:: INRIA PIQ program Strasbourg :::::::::: piq.inria.fr ::
:: :::::::::::::::::::::::::::::::::::: ☎ +33 368854536 ::
:: https://icube-icps.unistra.fr/index.php/Jens_Gustedt ::