[v2,4/4] c2y: Add function cnd_timedwait_base and mtx_timedlock_base

  For c11 threads, the mtx and cnd doesn't support for monotonic timedlock and timedwait;
So add two proposal function mtx_timedlock_base cnd_timedwait_base to do that.
The protype of these two functions is:
int mtx_timedlock_base(mtx_t *restrict m, int time_base, const struct timespec *restrict ts);
int cnd_timedwait_base(cnd_t *restrict c, mtx_t *restrict m, int time_base, const struct timespec *restrict ts);
The time_base at least can be TIME_UTC/TIME_MONOTONIC, the implementer can implement it with any provided
TIME_* base parameter provided in c2y time.h, if TIME_MONOTONIC can not natively supported, fallback to TIME_UTC
should provided, for other TIME_* base parameter, it's implementer's choice.

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
---
 conform/data/threads.h-data                  |  2 +
 htl/Versions                                 |  5 ++
 nptl/Versions                                |  5 ++
 sysdeps/pthread/Makefile                     |  2 +
 sysdeps/pthread/cnd_timedwait_base.c         | 29 +++++++++++
 sysdeps/pthread/mtx_timedlock_base.c         | 28 +++++++++++
 sysdeps/pthread/threads.h                    | 18 +++++++
 sysdeps/unix/sysv/linux/Versions             |  6 +++
 sysdeps/unix/sysv/linux/cnd_timedwait_base.c | 53 ++++++++++++++++++++
 sysdeps/unix/sysv/linux/mtx_timedlock_base.c | 50 ++++++++++++++++++
 sysdeps/unix/sysv/linux/thrd_priv.h          | 10 ++++
 11 files changed, 208 insertions(+)
 create mode 100644 sysdeps/pthread/cnd_timedwait_base.c
 create mode 100644 sysdeps/pthread/mtx_timedlock_base.c
 create mode 100644 sysdeps/unix/sysv/linux/cnd_timedwait_base.c
 create mode 100644 sysdeps/unix/sysv/linux/mtx_timedlock_base.c
  

On Wed, 21 Jun 2023, Yonggang Luo via Libc-alpha wrote:

> diff --git a/sysdeps/pthread/threads.h b/sysdeps/pthread/threads.h
> index d88d7a3ddd..4f61ad9236 100644
> --- a/sysdeps/pthread/threads.h
> +++ b/sysdeps/pthread/threads.h
> @@ -146,14 +146,22 @@ extern int mtx_lock (mtx_t *__mutex);
>  #ifndef __USE_TIME_BITS64
>  extern int mtx_timedlock (mtx_t *__restrict __mutex,
>  			  const struct timespec *__restrict __time_point);
> +extern int mtx_timedlock_base (mtx_t *__restrict __mutex, int time_base,
> +                               const struct timespec *__restrict __time_point);

As noted, this should be conditional on __USE_GNU.  Since you didn't make 
it conditional, I'd expect it to have failed the conform/ namespace tests 
- both for the mtx_timedlock_base name itself if there weren't incorrect 
conform/ changes in the patch series, and for the time_base parameter 
(parameters in installed headers should always have a leading __).  How 
did you test these patches?

> +extern int __REDIRECT (mtx_timedlock_base, (mtx_t *__restrict __mutex,
> +                                            int time_base,
> +                                            const struct timespec *__restrict
> +                                            __time_point),
> +                       __mtx_timedlock_base64);

Likewise, should be conditional on __USE_GNU and time_base should be 
__time_base.

> +extern int cnd_timedwait_base (cnd_t *__restrict __cond,
> +                               mtx_t *__restrict __mutex, int time_base,
> +                               const struct timespec *__restrict __time_point);

> +extern int __REDIRECT (cnd_timedwait_base, (cnd_t *__restrict __cond,
> +                                            mtx_t *__restrict __mutex,
> +                                            int time_base,
> +                                            const struct timespec *__restrict
> +                                            __time_point),

Likewise.
  

In addition to my previous comments, such new user-visible features should 
be documented in the manual, when they are added to families of functions 
that are already documented there (see threads.texi), and mentioned in a 
NEWS entry.
  

On Wed, Jun 21, 2023 at 4:41 AM Joseph Myers <joseph@codesourcery.com>
wrote:
>
> On Wed, 21 Jun 2023, Yonggang Luo via Libc-alpha wrote:
>
> > diff --git a/sysdeps/pthread/threads.h b/sysdeps/pthread/threads.h
> > index d88d7a3ddd..4f61ad9236 100644
> > --- a/sysdeps/pthread/threads.h
> > +++ b/sysdeps/pthread/threads.h
> > @@ -146,14 +146,22 @@ extern int mtx_lock (mtx_t *__mutex);
> >  #ifndef __USE_TIME_BITS64
> >  extern int mtx_timedlock (mtx_t *__restrict __mutex,
> >                         const struct timespec *__restrict __time_point);
> > +extern int mtx_timedlock_base (mtx_t *__restrict __mutex, int
time_base,
> > +                               const struct timespec *__restrict
__time_point);
>
> As noted, this should be conditional on __USE_GNU.  Since you didn't make
> it conditional, I'd expect it to have failed the conform/ namespace tests
> - both for the mtx_timedlock_base name itself if there weren't incorrect
> conform/ changes in the patch series, and for the time_base parameter
> (parameters in installed headers should always have a leading __).  How
> did you test these patches?

I am not testing these patches yet(as a new contributor for glibc, don't
know how to do that yet),
and for this patch, I'd like to know if the prototype of these two
functions is proper first

int mtx_timedlock_base(mtx_t *restrict m, int time_base, const struct
timespec *restrict ts);

int cnd_timedwait_base(cnd_t *restrict c, mtx_t *restrict m, int time_base,
const struct timespec *restrict ts);

The function name was suggested by Jens Gustedt, and indeed I also thought
about this name in the first place(because posix has cond_clockwait and
mutex_clocklock already). And seems enh also like this

If we have minimal agreement about this proposal, I'd like to add tests for
it. But still, I don't think
__USE_GNU is a good name for it, because it's for C2y or C3x, any better
option for this, so that it's not GNU restricted, for example, suppose MSVC
also wants to implement this?


>
> > +extern int __REDIRECT (mtx_timedlock_base, (mtx_t *__restrict __mutex,
> > +                                            int time_base,
> > +                                            const struct timespec
*__restrict
> > +                                            __time_point),
> > +                       __mtx_timedlock_base64);
>
> Likewise, should be conditional on __USE_GNU and time_base should be
> __time_base.
>
> > +extern int cnd_timedwait_base (cnd_t *__restrict __cond,
> > +                               mtx_t *__restrict __mutex, int
time_base,
> > +                               const struct timespec *__restrict
__time_point);
>
> > +extern int __REDIRECT (cnd_timedwait_base, (cnd_t *__restrict __cond,
> > +                                            mtx_t *__restrict __mutex,
> > +                                            int time_base,
> > +                                            const struct timespec
*__restrict
> > +                                            __time_point),
>
> Likewise.
>
> --
> Joseph S. Myers
> joseph@codesourcery.com



--
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo
  

On Wed, 2023-06-21 at 17:21 +0800, 罗勇刚(Yonggang Luo) via Libc-alpha
wrote:
> The function name was suggested by Jens Gustedt, and indeed I also thought
> about this name in the first place(because posix has cond_clockwait and
> mutex_clocklock already). And seems enh also like this
> 
> If we have minimal agreement about this proposal, I'd like to add tests for
> it. But still, I don't think
> __USE_GNU is a good name for it, because it's for C2y or C3x, any better
> option for this, so that it's not GNU restricted, for example, suppose MSVC
> also wants to implement this?

No, __USE_GNU does not mean it's GNU restricted, but mean it's a GNU
extension.  Other implementations can implement GNU extensions as well
if they wish (and doing so does not violate LGPL unless they copy the
implementation from Glibc).

Hmm, and do you have some misunderstanding about the relationship betwen
the C standard and Glibc?  Glibc implements the standard, but it's not
the standard.  If you want to add the functions into the standard you
need to submit it to WG14 first.  Before WG14 accept it, we cannot
declare the functions standard.  I've not seen your paper at
https://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_log.htm but
maybe I missed something.
  

Xi Ruoyao <xry111@xry111.site> 于 2023年6月21日周三 17:54写道：

> On Wed, 2023-06-21 at 17:21 +0800, 罗勇刚(Yonggang Luo) via Libc-alpha
> wrote:
> > The function name was suggested by Jens Gustedt, and indeed I also
> thought
> > about this name in the first place(because posix has cond_clockwait and
> > mutex_clocklock already). And seems enh also like this
> >
> > If we have minimal agreement about this proposal, I'd like to add tests
> for
> > it. But still, I don't think
> > __USE_GNU is a good name for it, because it's for C2y or C3x, any better
> > option for this, so that it's not GNU restricted, for example, suppose
> MSVC
> > also wants to implement this?
>
> No, __USE_GNU does not mean it's GNU restricted, but mean it's a GNU
> extension.  Other implementations can implement GNU extensions as well
> if they wish (and doing so does not violate LGPL unless they copy the
> implementation from Glibc).
>
> Hmm, and do you have some misunderstanding about the relationship betwen
> the C standard and Glibc?  Glibc implements the standard, but it's not
> the standard.  If you want to add the functions into the standard you
> need to submit it to WG14 first.  Before WG14 accept it, we cannot
> declare the functions standard.  I've not seen your paper at
> https://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_log.htm but
> maybe I missed something.
>

its not submit to wg14 yet, because this is not a totally new feature, I
need to implement it first to see if it's possible, and this is chicken/egg
problem, so I decided implement it first to receiving feedback, and after
minimal agreement received, I would submit proposal to wg14 if am qualified.

 Another reason I sumbit implementation first because I want use this in
Mesa before standardized.


> --
> Xi Ruoyao <xry111@xry111.site>
> School of Aerospace Science and Technology, Xidian University
>
  

On Wed, 2023-06-21 at 18:16 +0800, 罗勇刚(Yonggang Luo) wrote:
> its not submit to wg14 yet, because this is not a totally new feature,
> I need to implement it first to see if it's possible, and this is
> chicken/egg problem, so I decided implement it first to receiving
> feedback, and after minimal agreement received, I would submit
> proposal to wg14 if am qualified.

Then they are GNU extensions, for now.  When they are published by WG14
we can move from __USE_GNU to __USE_ISOC??.


> Another reason I sumbit implementation first because I want use this
> in Mesa before standardized.

Mesa uses -D_GNU_SOURCE in CFLAGS anyway, so __USE_GNU won't prevent you
from using it.
  

* 罗勇刚(Yonggang Luo):

> its not submit to wg14 yet, because this is not a totally new feature,
> I need to implement it first to see if it's possible, and this is
> chicken/egg problem, so I decided implement it first to receiving
> feedback, and after minimal agreement received, I would submit
> proposal to wg14 if am qualified.

You need to take this up with WG14.  This is not the right list for
that.

There is no reason to duplicate existing POSIX functionality or
extensions in glibc just because they might be included in a future
version of the C standard.  Usually, WG14 does not adopt actually
deployed interfaces, but makes up new ones (despite the “no invention,
without exception“ still in the charter).  In that case, we end up with
three incompatible interfaces, the POSIX one, our C prototype, and the
actual C interface.

Thanks,
Florian
  

On Wed, 21 Jun 2023, 罗勇刚(Yonggang Luo) via Libc-alpha wrote:

> I am not testing these patches yet(as a new contributor for glibc, don't
> know how to do that yet),

Please don't post untested patches without marking them very clearly as 
untested (and a good reason for them being untested).  If you have 
difficulty following the documentation on how to test glibc, please seek 
help on the libc-help mailing list.

> If we have minimal agreement about this proposal, I'd like to add tests for
> it. But still, I don't think
> __USE_GNU is a good name for it, because it's for C2y or C3x, any better
> option for this, so that it's not GNU restricted, for example, suppose MSVC
> also wants to implement this?

It would be a GNU extension unless and until it's adopted into some 
standard.

For example, exp10 was a GNU extension, conditional on __USE_GNU, until it 
was added to TS 18661-4; it was then conditioned on __GLIBC_USE 
(IEC_60559_FUNCS_EXT) in glibc (commit 
412cb261b0d66ef5251d7d1c8276b5c522d943b7), and, when parts of TS 18661-4 
were added to C2x, the conditionals in glibc were updated to make exp10 
visible for C2x (commit c3ce62cc0bd6e8a33629e2aabb7783a322e9189c).

A similar principle applies to any function added to glibc that's not in a 
standard but might be added to one in future: it should be conditional on 
__USE_GNU (rarely __USE_MISC in cases of extensions also present in other 
Unix-like libcs) and the conditional is changed in future if added to a 
standard.

This generally applies even if the interface name matches a pattern 
reserved in ISO C (for example, strdup - added to ISO C in C2x - is only 
conditionally declared, even though C90 reserves all str* names).
  

Hello Florian,

On Wed, 21 Jun 2023 12:40:45 +0200, Florian Weimer wrote:

> There is no reason to duplicate existing POSIX functionality or
> extensions in glibc just because they might be included in a future
> version of the C standard.  Usually, WG14 does not adopt actually
> deployed interfaces, but makes up new ones (despite the “no invention,
> without exception“ still in the charter).

You are exagerating a bit. C23 will integrate a bunch of POSIX
functions, verbatim. There is no "usually" here, it is discussed for
every individual function that we look at. And that is a tedious
case-by-case analysis.

Interfaces for time are a bit special because they were modeled along
POSIX but then changed names and specification of clocks / time bases.

> In that case, we end up with three incompatible interfaces, the
> POSIX one, our C prototype, and the actual C interface.

Yes, that would indeed be not good. The way forward here would be to
propose an integration of the POSIX feature into C2y that would most
probably need a new name and ABI for the reasons I mentioned. Such a
proposal can't happen before mid/end of 2024. If in the meantime one
would want to add a `mtx_…_np` (non-portable) function to a given C
library is certainly debadable. Where this could make sense is for
non-POSIX implementations.

For all of this to make sense, we first need solid implementations of
the three new optional time bases for the existing time interfaces, in
particular for non-POSIX implementations. This would then only make it
interesting for the committees to have new functions in C2y that
depend on these time base and which then, in turn, would make the
whole subset of functions more attractive to our users.


Thanks
Jₑₙₛ

PS: where I am fine to participate in this particular discussion with
glibc on time bases, please remove my name from other tagential
discussions about code identation or stuff like that. Please everybody
be a bit more careful, thanks.
  

On Wed, Jun 21, 2023 at 2:21 AM 罗勇刚(Yonggang Luo) <luoyonggang@gmail.com>
wrote:

>
>
> On Wed, Jun 21, 2023 at 4:41 AM Joseph Myers <joseph@codesourcery.com>
> wrote:
> >
> > On Wed, 21 Jun 2023, Yonggang Luo via Libc-alpha wrote:
> >
> > > diff --git a/sysdeps/pthread/threads.h b/sysdeps/pthread/threads.h
> > > index d88d7a3ddd..4f61ad9236 100644
> > > --- a/sysdeps/pthread/threads.h
> > > +++ b/sysdeps/pthread/threads.h
> > > @@ -146,14 +146,22 @@ extern int mtx_lock (mtx_t *__mutex);
> > >  #ifndef __USE_TIME_BITS64
> > >  extern int mtx_timedlock (mtx_t *__restrict __mutex,
> > >                         const struct timespec *__restrict
> __time_point);
> > > +extern int mtx_timedlock_base (mtx_t *__restrict __mutex, int
> time_base,
> > > +                               const struct timespec *__restrict
> __time_point);
> >
> > As noted, this should be conditional on __USE_GNU.  Since you didn't make
> > it conditional, I'd expect it to have failed the conform/ namespace tests
> > - both for the mtx_timedlock_base name itself if there weren't incorrect
> > conform/ changes in the patch series, and for the time_base parameter
> > (parameters in installed headers should always have a leading __).  How
> > did you test these patches?
>
> I am not testing these patches yet(as a new contributor for glibc, don't
> know how to do that yet),
> and for this patch, I'd like to know if the prototype of these two
> functions is proper first
>
> int mtx_timedlock_base(mtx_t *restrict m, int time_base, const struct
> timespec *restrict ts);
>
> int cnd_timedwait_base(cnd_t *restrict c, mtx_t *restrict m, int
> time_base, const struct timespec *restrict ts);
>
> The function name was suggested by Jens Gustedt, and indeed I also thought
> about this name in the first place(because posix has cond_clockwait and
> mutex_clocklock already). And seems enh also like this
>

well, to the extent that i think "pthreads that's also available on
Windows" is useful to some, sure, i'll continue to add the trivial inline
functions to bionic so that this is actually portable (
https://android.googlesource.com/platform/bionic/+/master/libc/include/bits/threads_inlines.h).
but for Android host tools themselves, i think we'll continue to use
std::thread or pthreads via mingw.

but my real feedback earlier was the same as what you're seeing here:
"since this is a WG14-driven thing, it should come as a proposal from there
first". anyone using bionic or glibc already has perfectly good pthread
apis, so no real need for this stuff until/unless it's in Windows. (and
last time i looked, Windows hadn't actually implemented the existing
<threads.h> stuff yet?)


> If we have minimal agreement about this proposal, I'd like to add tests
> for it. But still, I don't think
> __USE_GNU is a good name for it, because it's for C2y or C3x, any better
> option for this, so that it's not GNU restricted, for example, suppose MSVC
> also wants to implement this?
>
>
> >
> > > +extern int __REDIRECT (mtx_timedlock_base, (mtx_t *__restrict __mutex,
> > > +                                            int time_base,
> > > +                                            const struct timespec
> *__restrict
> > > +                                            __time_point),
> > > +                       __mtx_timedlock_base64);
> >
> > Likewise, should be conditional on __USE_GNU and time_base should be
> > __time_base.
> >
> > > +extern int cnd_timedwait_base (cnd_t *__restrict __cond,
> > > +                               mtx_t *__restrict __mutex, int
> time_base,
> > > +                               const struct timespec *__restrict
> __time_point);
> >
> > > +extern int __REDIRECT (cnd_timedwait_base, (cnd_t *__restrict __cond,
> > > +                                            mtx_t *__restrict __mutex,
> > > +                                            int time_base,
> > > +                                            const struct timespec
> *__restrict
> > > +                                            __time_point),
> >
> > Likewise.
> >
> > --
> > Joseph S. Myers
> > joseph@codesourcery.com
>
>
>
> --
>          此致
> 礼
> 罗勇刚
> Yours
>     sincerely,
> Yonggang Luo
>
  

On Wed, 21 Jun 2023, enh via Libc-alpha wrote:

> but my real feedback earlier was the same as what you're seeing here:
> "since this is a WG14-driven thing, it should come as a proposal from there
> first". anyone using bionic or glibc already has perfectly good pthread

And, since there is one bit that *is* already in C2x (three new time 
bases), that bit should be submitted on its own (with the fixes already 
identified), since that bit unambiguously makes sense as adding support 
for a C2x feature - independent of whether any further functions in this 
area, or time bases, ever get added to the C standard, or to other 
implementations that make them useful to add to glibc.
  

On Wed, Jun 21, 2023 at 10:31 PM enh <enh@google.com> wrote:
>
>
>
> On Wed, Jun 21, 2023 at 2:21 AM 罗勇刚(Yonggang Luo) <luoyonggang@gmail.com>
wrote:
>>
>>
>>
>> On Wed, Jun 21, 2023 at 4:41 AM Joseph Myers <joseph@codesourcery.com>
wrote:
>> >
>> > On Wed, 21 Jun 2023, Yonggang Luo via Libc-alpha wrote:
>> >
>> > > diff --git a/sysdeps/pthread/threads.h b/sysdeps/pthread/threads.h
>> > > index d88d7a3ddd..4f61ad9236 100644
>> > > --- a/sysdeps/pthread/threads.h
>> > > +++ b/sysdeps/pthread/threads.h
>> > > @@ -146,14 +146,22 @@ extern int mtx_lock (mtx_t *__mutex);
>> > >  #ifndef __USE_TIME_BITS64
>> > >  extern int mtx_timedlock (mtx_t *__restrict __mutex,
>> > >                         const struct timespec *__restrict
__time_point);
>> > > +extern int mtx_timedlock_base (mtx_t *__restrict __mutex, int
time_base,
>> > > +                               const struct timespec *__restrict
__time_point);
>> >
>> > As noted, this should be conditional on __USE_GNU.  Since you didn't
make
>> > it conditional, I'd expect it to have failed the conform/ namespace
tests
>> > - both for the mtx_timedlock_base name itself if there weren't
incorrect
>> > conform/ changes in the patch series, and for the time_base parameter
>> > (parameters in installed headers should always have a leading __).  How
>> > did you test these patches?
>>
>> I am not testing these patches yet(as a new contributor for glibc, don't
know how to do that yet),
>> and for this patch, I'd like to know if the prototype of these two
functions is proper first
>>
>> int mtx_timedlock_base(mtx_t *restrict m, int time_base, const struct
timespec *restrict ts);
>>
>> int cnd_timedwait_base(cnd_t *restrict c, mtx_t *restrict m, int
time_base, const struct timespec *restrict ts);
>>
>> The function name was suggested by Jens Gustedt, and indeed I also
thought about this name in the first place(because posix has cond_clockwait
and mutex_clocklock already). And seems enh also like this
>
>
> well, to the extent that i think "pthreads that's also available on
Windows" is useful to some, sure, i'll continue to add the trivial inline
functions to bionic so that this is actually portable (
https://android.googlesource.com/platform/bionic/+/master/libc/include/bits/threads_inlines.h).
but for Android host tools themselves, i think we'll continue to use
std::thread or pthreads via mingw.
>
> but my real feedback earlier was the same as what you're seeing here:
"since this is a WG14-driven thing, it should come as a proposal from there
first". anyone using bionic or glibc already has perfectly good pthread
apis, so no real need for this stuff until/unless it's in Windows. (and
last time i looked, Windows hadn't actually implemented the existing
<threads.h> stuff yet?)

Yeah, you are correct, windows msvc doesn't have either pthread or c11
threads, and pthreads is so huge, so there is multiple third-party c11
threads implementation for MSVC, that's why I wanna c2y threads comes with
monotonic mtx_timedlock cnd_timedwait support, so that the third-party c11
threads implementation have a consistence API to implement.

So my question, anyone in this threads have suggestion about the newly
proposed API:

 int mtx_timedlock_base (mtx_t*, int, const struct timespec*);
 int cnd_timedwait_base (cnd_t*, mtx_t*, int, const struct timespec*);

>
>>
>> If we have minimal agreement about this proposal, I'd like to add tests
for it. But still, I don't think
>> __USE_GNU is a good name for it, because it's for C2y or C3x, any better
option for this, so that it's not GNU restricted, for example, suppose MSVC
also wants to implement this?
>>
>>
>> >
>> > > +extern int __REDIRECT (mtx_timedlock_base, (mtx_t *__restrict
__mutex,
>> > > +                                            int time_base,
>> > > +                                            const struct timespec
*__restrict
>> > > +                                            __time_point),
>> > > +                       __mtx_timedlock_base64);
>> >
>> > Likewise, should be conditional on __USE_GNU and time_base should be
>> > __time_base.
>> >
>> > > +extern int cnd_timedwait_base (cnd_t *__restrict __cond,
>> > > +                               mtx_t *__restrict __mutex, int
time_base,
>> > > +                               const struct timespec *__restrict
__time_point);
>> >
>> > > +extern int __REDIRECT (cnd_timedwait_base, (cnd_t *__restrict
__cond,
>> > > +                                            mtx_t *__restrict
__mutex,
>> > > +                                            int time_base,
>> > > +                                            const struct timespec
*__restrict
>> > > +                                            __time_point),
>> >
>> > Likewise.
>> >
>> > --
>> > Joseph S. Myers
>> > joseph@codesourcery.com
>>
>>
>>
>> --
>>          此致
>> 礼
>> 罗勇刚
>> Yours
>>     sincerely,
>> Yonggang Luo



--
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo
  

On Wed, Jun 21, 2023 at 11:39 AM 罗勇刚(Yonggang Luo) <luoyonggang@gmail.com>
wrote:

>
>
> On Wed, Jun 21, 2023 at 10:31 PM enh <enh@google.com> wrote:
> >
> >
> >
> > On Wed, Jun 21, 2023 at 2:21 AM 罗勇刚(Yonggang Luo) <luoyonggang@gmail.com>
> wrote:
> >>
> >>
> >>
> >> On Wed, Jun 21, 2023 at 4:41 AM Joseph Myers <joseph@codesourcery.com>
> wrote:
> >> >
> >> > On Wed, 21 Jun 2023, Yonggang Luo via Libc-alpha wrote:
> >> >
> >> > > diff --git a/sysdeps/pthread/threads.h b/sysdeps/pthread/threads.h
> >> > > index d88d7a3ddd..4f61ad9236 100644
> >> > > --- a/sysdeps/pthread/threads.h
> >> > > +++ b/sysdeps/pthread/threads.h
> >> > > @@ -146,14 +146,22 @@ extern int mtx_lock (mtx_t *__mutex);
> >> > >  #ifndef __USE_TIME_BITS64
> >> > >  extern int mtx_timedlock (mtx_t *__restrict __mutex,
> >> > >                         const struct timespec *__restrict
> __time_point);
> >> > > +extern int mtx_timedlock_base (mtx_t *__restrict __mutex, int
> time_base,
> >> > > +                               const struct timespec *__restrict
> __time_point);
> >> >
> >> > As noted, this should be conditional on __USE_GNU.  Since you didn't
> make
> >> > it conditional, I'd expect it to have failed the conform/ namespace
> tests
> >> > - both for the mtx_timedlock_base name itself if there weren't
> incorrect
> >> > conform/ changes in the patch series, and for the time_base parameter
> >> > (parameters in installed headers should always have a leading __).
> How
> >> > did you test these patches?
> >>
> >> I am not testing these patches yet(as a new contributor for glibc,
> don't know how to do that yet),
> >> and for this patch, I'd like to know if the prototype of these two
> functions is proper first
> >>
> >> int mtx_timedlock_base(mtx_t *restrict m, int time_base, const struct
> timespec *restrict ts);
> >>
> >> int cnd_timedwait_base(cnd_t *restrict c, mtx_t *restrict m, int
> time_base, const struct timespec *restrict ts);
> >>
> >> The function name was suggested by Jens Gustedt, and indeed I also
> thought about this name in the first place(because posix has cond_clockwait
> and mutex_clocklock already). And seems enh also like this
> >
> >
> > well, to the extent that i think "pthreads that's also available on
> Windows" is useful to some, sure, i'll continue to add the trivial inline
> functions to bionic so that this is actually portable (
> https://android.googlesource.com/platform/bionic/+/master/libc/include/bits/threads_inlines.h).
> but for Android host tools themselves, i think we'll continue to use
> std::thread or pthreads via mingw.
> >
> > but my real feedback earlier was the same as what you're seeing here:
> "since this is a WG14-driven thing, it should come as a proposal from there
> first". anyone using bionic or glibc already has perfectly good pthread
> apis, so no real need for this stuff until/unless it's in Windows. (and
> last time i looked, Windows hadn't actually implemented the existing
> <threads.h> stuff yet?)
>
> Yeah, you are correct, windows msvc doesn't have either pthread or c11
> threads, and pthreads is so huge, so there is multiple third-party c11
> threads implementation for MSVC, that's why I wanna c2y threads comes with
> monotonic mtx_timedlock cnd_timedwait support, so that the third-party c11
> threads implementation have a consistence API to implement.
>

if MS didn't bother to implement the C11 functions, why do you think they'd
implement any future additions?


> So my question, anyone in this threads have suggestion about the newly
> proposed API:
>
>  int mtx_timedlock_base (mtx_t*, int, const struct timespec*);
>  int cnd_timedwait_base (cnd_t*, mtx_t*, int, const struct timespec*);
>

don't existing functions put the `int __base` last? sounds like a question
for WG14 rather than c library implementors though --- as long as this
isn't supported on the platform that doesn't have pthreads, it's not
filling any obvious need.


> >
> >>
> >> If we have minimal agreement about this proposal, I'd like to add tests
> for it. But still, I don't think
> >> __USE_GNU is a good name for it, because it's for C2y or C3x, any
> better option for this, so that it's not GNU restricted, for example,
> suppose MSVC also wants to implement this?
> >>
> >>
> >> >
> >> > > +extern int __REDIRECT (mtx_timedlock_base, (mtx_t *__restrict
> __mutex,
> >> > > +                                            int time_base,
> >> > > +                                            const struct timespec
> *__restrict
> >> > > +                                            __time_point),
> >> > > +                       __mtx_timedlock_base64);
> >> >
> >> > Likewise, should be conditional on __USE_GNU and time_base should be
> >> > __time_base.
> >> >
> >> > > +extern int cnd_timedwait_base (cnd_t *__restrict __cond,
> >> > > +                               mtx_t *__restrict __mutex, int
> time_base,
> >> > > +                               const struct timespec *__restrict
> __time_point);
> >> >
> >> > > +extern int __REDIRECT (cnd_timedwait_base, (cnd_t *__restrict
> __cond,
> >> > > +                                            mtx_t *__restrict
> __mutex,
> >> > > +                                            int time_base,
> >> > > +                                            const struct timespec
> *__restrict
> >> > > +                                            __time_point),
> >> >
> >> > Likewise.
> >> >
> >> > --
> >> > Joseph S. Myers
> >> > joseph@codesourcery.com
> >>
> >>
> >>
> >> --
> >>          此致
> >> 礼
> >> 罗勇刚
> >> Yours
> >>     sincerely,
> >> Yonggang Luo
>
>
>
> --
>          此致
> 礼
> 罗勇刚
> Yours
>     sincerely,
> Yonggang Luo
>
  

On Thu, Jun 22, 2023 at 3:05 AM enh <enh@google.com> wrote:
>
>
>
> On Wed, Jun 21, 2023 at 11:39 AM 罗勇刚(Yonggang Luo) <luoyonggang@gmail.com>
wrote:
>>
>>
>>
>> On Wed, Jun 21, 2023 at 10:31 PM enh <enh@google.com> wrote:
>> >
>> >
>> >
>> > On Wed, Jun 21, 2023 at 2:21 AM 罗勇刚(Yonggang Luo) <
luoyonggang@gmail.com> wrote:
>> >>
>> >>
>> >>
>> >> On Wed, Jun 21, 2023 at 4:41 AM Joseph Myers <joseph@codesourcery.com>
wrote:
>> >> >
>> >> > On Wed, 21 Jun 2023, Yonggang Luo via Libc-alpha wrote:
>> >> >
>> >> > > diff --git a/sysdeps/pthread/threads.h b/sysdeps/pthread/threads.h
>> >> > > index d88d7a3ddd..4f61ad9236 100644
>> >> > > --- a/sysdeps/pthread/threads.h
>> >> > > +++ b/sysdeps/pthread/threads.h
>> >> > > @@ -146,14 +146,22 @@ extern int mtx_lock (mtx_t *__mutex);
>> >> > >  #ifndef __USE_TIME_BITS64
>> >> > >  extern int mtx_timedlock (mtx_t *__restrict __mutex,
>> >> > >                         const struct timespec *__restrict
__time_point);
>> >> > > +extern int mtx_timedlock_base (mtx_t *__restrict __mutex, int
time_base,
>> >> > > +                               const struct timespec *__restrict
__time_point);
>> >> >
>> >> > As noted, this should be conditional on __USE_GNU.  Since you
didn't make
>> >> > it conditional, I'd expect it to have failed the conform/ namespace
tests
>> >> > - both for the mtx_timedlock_base name itself if there weren't
incorrect
>> >> > conform/ changes in the patch series, and for the time_base
parameter
>> >> > (parameters in installed headers should always have a leading __).
How
>> >> > did you test these patches?
>> >>
>> >> I am not testing these patches yet(as a new contributor for glibc,
don't know how to do that yet),
>> >> and for this patch, I'd like to know if the prototype of these two
functions is proper first
>> >>
>> >> int mtx_timedlock_base(mtx_t *restrict m, int time_base, const struct
timespec *restrict ts);
>> >>
>> >> int cnd_timedwait_base(cnd_t *restrict c, mtx_t *restrict m, int
time_base, const struct timespec *restrict ts);
>> >>
>> >> The function name was suggested by Jens Gustedt, and indeed I also
thought about this name in the first place(because posix has cond_clockwait
and mutex_clocklock already). And seems enh also like this
>> >
>> >
>> > well, to the extent that i think "pthreads that's also available on
Windows" is useful to some, sure, i'll continue to add the trivial inline
functions to bionic so that this is actually portable (
https://android.googlesource.com/platform/bionic/+/master/libc/include/bits/threads_inlines.h).
but for Android host tools themselves, i think we'll continue to use
std::thread or pthreads via mingw.
>> >
>> > but my real feedback earlier was the same as what you're seeing here:
"since this is a WG14-driven thing, it should come as a proposal from there
first". anyone using bionic or glibc already has perfectly good pthread
apis, so no real need for this stuff until/unless it's in Windows. (and
last time i looked, Windows hadn't actually implemented the existing
<threads.h> stuff yet?)
>>
>> Yeah, you are correct, windows msvc doesn't have either pthread or c11
threads, and pthreads is so huge, so there is multiple third-party c11
threads implementation for MSVC, that's why I wanna c2y threads comes with
monotonic mtx_timedlock cnd_timedwait support, so that the third-party c11
threads implementation have a consistence API to implement.
>
>
> if MS didn't bother to implement the C11 functions, why do you think
they'd implement any future additions?

I don't bother MS if they will implement the C11 functions, I just want a
set of cross-platform threads api(c11 threads) to use (non-posix
non-pthreads), we can always polyfill that API when the native libc doesn't
support that.
The API is more important than who would implement it

>
>>
>> So my question, anyone in this threads have suggestion about the newly
proposed API:
>>
>>  int mtx_timedlock_base (mtx_t*, int, const struct timespec*);
>>  int cnd_timedwait_base (cnd_t*, mtx_t*, int, const struct timespec*);
>
>
> don't existing functions put the `int __base` last? sounds like a
question for WG14 rather than c library implementors though --- as long as
this isn't supported on the platform that doesn't have pthreads, it's not
filling any obvious need.
>
>>
>> >
>> >>
>> >> If we have minimal agreement about this proposal, I'd like to add
tests for it. But still, I don't think
>> >> __USE_GNU is a good name for it, because it's for C2y or C3x, any
better option for this, so that it's not GNU restricted, for example,
suppose MSVC also wants to implement this?
>> >>
>> >>
>> >> >
>> >> > > +extern int __REDIRECT (mtx_timedlock_base, (mtx_t *__restrict
__mutex,
>> >> > > +                                            int time_base,
>> >> > > +                                            const struct
timespec *__restrict
>> >> > > +                                            __time_point),
>> >> > > +                       __mtx_timedlock_base64);
>> >> >
>> >> > Likewise, should be conditional on __USE_GNU and time_base should be
>> >> > __time_base.
>> >> >
>> >> > > +extern int cnd_timedwait_base (cnd_t *__restrict __cond,
>> >> > > +                               mtx_t *__restrict __mutex, int
time_base,
>> >> > > +                               const struct timespec *__restrict
__time_point);
>> >> >
>> >> > > +extern int __REDIRECT (cnd_timedwait_base, (cnd_t *__restrict
__cond,
>> >> > > +                                            mtx_t *__restrict
__mutex,
>> >> > > +                                            int time_base,
>> >> > > +                                            const struct
timespec *__restrict
>> >> > > +                                            __time_point),
>> >> >
>> >> > Likewise.
>> >> >
>> >> > --
>> >> > Joseph S. Myers
>> >> > joseph@codesourcery.com
>> >>
>> >>
>> >>
>> >> --
>> >>          此致
>> >> 礼
>> >> 罗勇刚
>> >> Yours
>> >>     sincerely,
>> >> Yonggang Luo
>>
>>
>>
>> --
>>          此致
>> 礼
>> 罗勇刚
>> Yours
>>     sincerely,
>> Yonggang Luo



--
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo
  

On Wed, Jun 21, 2023 at 12:08 PM 罗勇刚(Yonggang Luo) <luoyonggang@gmail.com>
wrote:

>
>
> On Thu, Jun 22, 2023 at 3:05 AM enh <enh@google.com> wrote:
> >
> >
> >
> > On Wed, Jun 21, 2023 at 11:39 AM 罗勇刚(Yonggang Luo) <
> luoyonggang@gmail.com> wrote:
> >>
> >>
> >>
> >> On Wed, Jun 21, 2023 at 10:31 PM enh <enh@google.com> wrote:
> >> >
> >> >
> >> >
> >> > On Wed, Jun 21, 2023 at 2:21 AM 罗勇刚(Yonggang Luo) <
> luoyonggang@gmail.com> wrote:
> >> >>
> >> >>
> >> >>
> >> >> On Wed, Jun 21, 2023 at 4:41 AM Joseph Myers <
> joseph@codesourcery.com> wrote:
> >> >> >
> >> >> > On Wed, 21 Jun 2023, Yonggang Luo via Libc-alpha wrote:
> >> >> >
> >> >> > > diff --git a/sysdeps/pthread/threads.h
> b/sysdeps/pthread/threads.h
> >> >> > > index d88d7a3ddd..4f61ad9236 100644
> >> >> > > --- a/sysdeps/pthread/threads.h
> >> >> > > +++ b/sysdeps/pthread/threads.h
> >> >> > > @@ -146,14 +146,22 @@ extern int mtx_lock (mtx_t *__mutex);
> >> >> > >  #ifndef __USE_TIME_BITS64
> >> >> > >  extern int mtx_timedlock (mtx_t *__restrict __mutex,
> >> >> > >                         const struct timespec *__restrict
> __time_point);
> >> >> > > +extern int mtx_timedlock_base (mtx_t *__restrict __mutex, int
> time_base,
> >> >> > > +                               const struct timespec
> *__restrict __time_point);
> >> >> >
> >> >> > As noted, this should be conditional on __USE_GNU.  Since you
> didn't make
> >> >> > it conditional, I'd expect it to have failed the conform/
> namespace tests
> >> >> > - both for the mtx_timedlock_base name itself if there weren't
> incorrect
> >> >> > conform/ changes in the patch series, and for the time_base
> parameter
> >> >> > (parameters in installed headers should always have a leading
> __).  How
> >> >> > did you test these patches?
> >> >>
> >> >> I am not testing these patches yet(as a new contributor for glibc,
> don't know how to do that yet),
> >> >> and for this patch, I'd like to know if the prototype of these two
> functions is proper first
> >> >>
> >> >> int mtx_timedlock_base(mtx_t *restrict m, int time_base, const
> struct timespec *restrict ts);
> >> >>
> >> >> int cnd_timedwait_base(cnd_t *restrict c, mtx_t *restrict m, int
> time_base, const struct timespec *restrict ts);
> >> >>
> >> >> The function name was suggested by Jens Gustedt, and indeed I also
> thought about this name in the first place(because posix has cond_clockwait
> and mutex_clocklock already). And seems enh also like this
> >> >
> >> >
> >> > well, to the extent that i think "pthreads that's also available on
> Windows" is useful to some, sure, i'll continue to add the trivial inline
> functions to bionic so that this is actually portable (
> https://android.googlesource.com/platform/bionic/+/master/libc/include/bits/threads_inlines.h).
> but for Android host tools themselves, i think we'll continue to use
> std::thread or pthreads via mingw.
> >> >
> >> > but my real feedback earlier was the same as what you're seeing here:
> "since this is a WG14-driven thing, it should come as a proposal from there
> first". anyone using bionic or glibc already has perfectly good pthread
> apis, so no real need for this stuff until/unless it's in Windows. (and
> last time i looked, Windows hadn't actually implemented the existing
> <threads.h> stuff yet?)
> >>
> >> Yeah, you are correct, windows msvc doesn't have either pthread or c11
> threads, and pthreads is so huge, so there is multiple third-party c11
> threads implementation for MSVC, that's why I wanna c2y threads comes with
> monotonic mtx_timedlock cnd_timedwait support, so that the third-party c11
> threads implementation have a consistence API to implement.
> >
> >
> > if MS didn't bother to implement the C11 functions, why do you think
> they'd implement any future additions?
>
> I don't bother MS if they will implement the C11 functions, I just want a
> set of cross-platform threads api(c11 threads) to use (non-posix
> non-pthreads), we can always polyfill that API when the native libc doesn't
> support that.
> The API is more important than who would implement it
>

if you're the only person implementing it _and_ the only person using it
... it doesn't really matter what you call it? just put _something_ in your
code, and worry about changing the name/signature if/when WG14 adds
something equivalent.


> >
> >>
> >> So my question, anyone in this threads have suggestion about the newly
> proposed API:
> >>
> >>  int mtx_timedlock_base (mtx_t*, int, const struct timespec*);
> >>  int cnd_timedwait_base (cnd_t*, mtx_t*, int, const struct timespec*);
> >
> >
> > don't existing functions put the `int __base` last? sounds like a
> question for WG14 rather than c library implementors though --- as long as
> this isn't supported on the platform that doesn't have pthreads, it's not
> filling any obvious need.
> >
> >>
> >> >
> >> >>
> >> >> If we have minimal agreement about this proposal, I'd like to add
> tests for it. But still, I don't think
> >> >> __USE_GNU is a good name for it, because it's for C2y or C3x, any
> better option for this, so that it's not GNU restricted, for example,
> suppose MSVC also wants to implement this?
> >> >>
> >> >>
> >> >> >
> >> >> > > +extern int __REDIRECT (mtx_timedlock_base, (mtx_t *__restrict
> __mutex,
> >> >> > > +                                            int time_base,
> >> >> > > +                                            const struct
> timespec *__restrict
> >> >> > > +                                            __time_point),
> >> >> > > +                       __mtx_timedlock_base64);
> >> >> >
> >> >> > Likewise, should be conditional on __USE_GNU and time_base should
> be
> >> >> > __time_base.
> >> >> >
> >> >> > > +extern int cnd_timedwait_base (cnd_t *__restrict __cond,
> >> >> > > +                               mtx_t *__restrict __mutex, int
> time_base,
> >> >> > > +                               const struct timespec
> *__restrict __time_point);
> >> >> >
> >> >> > > +extern int __REDIRECT (cnd_timedwait_base, (cnd_t *__restrict
> __cond,
> >> >> > > +                                            mtx_t *__restrict
> __mutex,
> >> >> > > +                                            int time_base,
> >> >> > > +                                            const struct
> timespec *__restrict
> >> >> > > +                                            __time_point),
> >> >> >
> >> >> > Likewise.
> >> >> >
> >> >> > --
> >> >> > Joseph S. Myers
> >> >> > joseph@codesourcery.com
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >>          此致
> >> >> 礼
> >> >> 罗勇刚
> >> >> Yours
> >> >>     sincerely,
> >> >> Yonggang Luo
> >>
> >>
> >>
> >> --
> >>          此致
> >> 礼
> >> 罗勇刚
> >> Yours
> >>     sincerely,
> >> Yonggang Luo
>
>
>
> --
>          此致
> 礼
> 罗勇刚
> Yours
>     sincerely,
> Yonggang Luo
>
  

On Thu, Jun 22, 2023 at 3:18 AM enh <enh@google.com> wrote:
>
>
>
> On Wed, Jun 21, 2023 at 12:08 PM 罗勇刚(Yonggang Luo) <luoyonggang@gmail.com>
wrote:
>>
>>
>>
>> On Thu, Jun 22, 2023 at 3:05 AM enh <enh@google.com> wrote:
>> >
>> >
>> >
>> > On Wed, Jun 21, 2023 at 11:39 AM 罗勇刚(Yonggang Luo) <
luoyonggang@gmail.com> wrote:
>> >>
>> >>
>> >>
>> >> On Wed, Jun 21, 2023 at 10:31 PM enh <enh@google.com> wrote:
>> >> >
>> >> >
>> >> >
>> >> > On Wed, Jun 21, 2023 at 2:21 AM 罗勇刚(Yonggang Luo) <
luoyonggang@gmail.com> wrote:
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Wed, Jun 21, 2023 at 4:41 AM Joseph Myers <
joseph@codesourcery.com> wrote:
>> >> >> >
>> >> >> > On Wed, 21 Jun 2023, Yonggang Luo via Libc-alpha wrote:
>> >> >> >
>> >> >> > > diff --git a/sysdeps/pthread/threads.h
b/sysdeps/pthread/threads.h
>> >> >> > > index d88d7a3ddd..4f61ad9236 100644
>> >> >> > > --- a/sysdeps/pthread/threads.h
>> >> >> > > +++ b/sysdeps/pthread/threads.h
>> >> >> > > @@ -146,14 +146,22 @@ extern int mtx_lock (mtx_t *__mutex);
>> >> >> > >  #ifndef __USE_TIME_BITS64
>> >> >> > >  extern int mtx_timedlock (mtx_t *__restrict __mutex,
>> >> >> > >                         const struct timespec *__restrict
__time_point);
>> >> >> > > +extern int mtx_timedlock_base (mtx_t *__restrict __mutex, int
time_base,
>> >> >> > > +                               const struct timespec
*__restrict __time_point);
>> >> >> >
>> >> >> > As noted, this should be conditional on __USE_GNU.  Since you
didn't make
>> >> >> > it conditional, I'd expect it to have failed the conform/
namespace tests
>> >> >> > - both for the mtx_timedlock_base name itself if there weren't
incorrect
>> >> >> > conform/ changes in the patch series, and for the time_base
parameter
>> >> >> > (parameters in installed headers should always have a leading
__).  How
>> >> >> > did you test these patches?
>> >> >>
>> >> >> I am not testing these patches yet(as a new contributor for glibc,
don't know how to do that yet),
>> >> >> and for this patch, I'd like to know if the prototype of these two
functions is proper first
>> >> >>
>> >> >> int mtx_timedlock_base(mtx_t *restrict m, int time_base, const
struct timespec *restrict ts);
>> >> >>
>> >> >> int cnd_timedwait_base(cnd_t *restrict c, mtx_t *restrict m, int
time_base, const struct timespec *restrict ts);
>> >> >>
>> >> >> The function name was suggested by Jens Gustedt, and indeed I also
thought about this name in the first place(because posix has cond_clockwait
and mutex_clocklock already). And seems enh also like this
>> >> >
>> >> >
>> >> > well, to the extent that i think "pthreads that's also available on
Windows" is useful to some, sure, i'll continue to add the trivial inline
functions to bionic so that this is actually portable (
https://android.googlesource.com/platform/bionic/+/master/libc/include/bits/threads_inlines.h).
but for Android host tools themselves, i think we'll continue to use
std::thread or pthreads via mingw.
>> >> >
>> >> > but my real feedback earlier was the same as what you're seeing
here: "since this is a WG14-driven thing, it should come as a proposal from
there first". anyone using bionic or glibc already has perfectly good
pthread apis, so no real need for this stuff until/unless it's in Windows.
(and last time i looked, Windows hadn't actually implemented the existing
<threads.h> stuff yet?)
>> >>
>> >> Yeah, you are correct, windows msvc doesn't have either pthread or
c11 threads, and pthreads is so huge, so there is multiple third-party c11
threads implementation for MSVC, that's why I wanna c2y threads comes with
monotonic mtx_timedlock cnd_timedwait support, so that the third-party c11
threads implementation have a consistence API to implement.
>> >
>> >
>> > if MS didn't bother to implement the C11 functions, why do you think
they'd implement any future additions?
>>
>> I don't bother MS if they will implement the C11 functions, I just want
a set of cross-platform threads api(c11 threads) to use (non-posix
non-pthreads), we can always polyfill that API when the native libc doesn't
support that.
>> The API is more important than who would implement it
>
>
> if you're the only person implementing it _and_ the only person using it
... it doesn't really matter what you call it? just put _something_ in your
code, and worry about changing the name/signature if/when WG14 adds
something equivalent.

I am not the only person implementing it _and_ the only person using it
obviously, I am just the only person that want to improve the c11 threads
api currently

>
>>
>> >
>> >>
>> >> So my question, anyone in this threads have suggestion about the
newly proposed API:
>> >>
>> >>  int mtx_timedlock_base (mtx_t*, int, const struct timespec*);
>> >>  int cnd_timedwait_base (cnd_t*, mtx_t*, int, const struct timespec*);
>> >
>> >
>> > don't existing functions put the `int __base` last? sounds like a
question for WG14 rather than c library implementors though --- as long as
this isn't supported on the platform that doesn't have pthreads, it's not
filling any obvious need.
>> >
>> >>
>> >> >
>> >> >>
>> >> >> If we have minimal agreement about this proposal, I'd like to add
tests for it. But still, I don't think
>> >> >> __USE_GNU is a good name for it, because it's for C2y or C3x, any
better option for this, so that it's not GNU restricted, for example,
suppose MSVC also wants to implement this?
>> >> >>
>> >> >>
>> >> >> >
>> >> >> > > +extern int __REDIRECT (mtx_timedlock_base, (mtx_t *__restrict
__mutex,
>> >> >> > > +                                            int time_base,
>> >> >> > > +                                            const struct
timespec *__restrict
>> >> >> > > +                                            __time_point),
>> >> >> > > +                       __mtx_timedlock_base64);
>> >> >> >
>> >> >> > Likewise, should be conditional on __USE_GNU and time_base
should be
>> >> >> > __time_base.
>> >> >> >
>> >> >> > > +extern int cnd_timedwait_base (cnd_t *__restrict __cond,
>> >> >> > > +                               mtx_t *__restrict __mutex, int
time_base,
>> >> >> > > +                               const struct timespec
*__restrict __time_point);
>> >> >> >
>> >> >> > > +extern int __REDIRECT (cnd_timedwait_base, (cnd_t *__restrict
__cond,
>> >> >> > > +                                            mtx_t *__restrict
__mutex,
>> >> >> > > +                                            int time_base,
>> >> >> > > +                                            const struct
timespec *__restrict
>> >> >> > > +                                            __time_point),
>> >> >> >
>> >> >> > Likewise.
>> >> >> >
>> >> >> > --
>> >> >> > Joseph S. Myers
>> >> >> > joseph@codesourcery.com
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >>          此致
>> >> >> 礼
>> >> >> 罗勇刚
>> >> >> Yours
>> >> >>     sincerely,
>> >> >> Yonggang Luo
>> >>
>> >>
>> >>
>> >> --
>> >>          此致
>> >> 礼
>> >> 罗勇刚
>> >> Yours
>> >>     sincerely,
>> >> Yonggang Luo
>>
>>
>>
>> --
>>          此致
>> 礼
>> 罗勇刚
>> Yours
>>     sincerely,
>> Yonggang Luo



--
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo
  

On Wed, Jun 21, 2023 at 12:38 PM 罗勇刚(Yonggang Luo) <luoyonggang@gmail.com>
wrote:

>
>
> On Thu, Jun 22, 2023 at 3:18 AM enh <enh@google.com> wrote:
> >
> >
> >
> > On Wed, Jun 21, 2023 at 12:08 PM 罗勇刚(Yonggang Luo) <
> luoyonggang@gmail.com> wrote:
> >>
> >>
> >>
> >> On Thu, Jun 22, 2023 at 3:05 AM enh <enh@google.com> wrote:
> >> >
> >> >
> >> >
> >> > On Wed, Jun 21, 2023 at 11:39 AM 罗勇刚(Yonggang Luo) <
> luoyonggang@gmail.com> wrote:
> >> >>
> >> >>
> >> >>
> >> >> On Wed, Jun 21, 2023 at 10:31 PM enh <enh@google.com> wrote:
> >> >> >
> >> >> >
> >> >> >
> >> >> > On Wed, Jun 21, 2023 at 2:21 AM 罗勇刚(Yonggang Luo) <
> luoyonggang@gmail.com> wrote:
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> On Wed, Jun 21, 2023 at 4:41 AM Joseph Myers <
> joseph@codesourcery.com> wrote:
> >> >> >> >
> >> >> >> > On Wed, 21 Jun 2023, Yonggang Luo via Libc-alpha wrote:
> >> >> >> >
> >> >> >> > > diff --git a/sysdeps/pthread/threads.h
> b/sysdeps/pthread/threads.h
> >> >> >> > > index d88d7a3ddd..4f61ad9236 100644
> >> >> >> > > --- a/sysdeps/pthread/threads.h
> >> >> >> > > +++ b/sysdeps/pthread/threads.h
> >> >> >> > > @@ -146,14 +146,22 @@ extern int mtx_lock (mtx_t *__mutex);
> >> >> >> > >  #ifndef __USE_TIME_BITS64
> >> >> >> > >  extern int mtx_timedlock (mtx_t *__restrict __mutex,
> >> >> >> > >                         const struct timespec *__restrict
> __time_point);
> >> >> >> > > +extern int mtx_timedlock_base (mtx_t *__restrict __mutex,
> int time_base,
> >> >> >> > > +                               const struct timespec
> *__restrict __time_point);
> >> >> >> >
> >> >> >> > As noted, this should be conditional on __USE_GNU.  Since you
> didn't make
> >> >> >> > it conditional, I'd expect it to have failed the conform/
> namespace tests
> >> >> >> > - both for the mtx_timedlock_base name itself if there weren't
> incorrect
> >> >> >> > conform/ changes in the patch series, and for the time_base
> parameter
> >> >> >> > (parameters in installed headers should always have a leading
> __).  How
> >> >> >> > did you test these patches?
> >> >> >>
> >> >> >> I am not testing these patches yet(as a new contributor for
> glibc, don't know how to do that yet),
> >> >> >> and for this patch, I'd like to know if the prototype of these
> two functions is proper first
> >> >> >>
> >> >> >> int mtx_timedlock_base(mtx_t *restrict m, int time_base, const
> struct timespec *restrict ts);
> >> >> >>
> >> >> >> int cnd_timedwait_base(cnd_t *restrict c, mtx_t *restrict m, int
> time_base, const struct timespec *restrict ts);
> >> >> >>
> >> >> >> The function name was suggested by Jens Gustedt, and indeed I
> also thought about this name in the first place(because posix has
> cond_clockwait and mutex_clocklock already). And seems enh also like this
> >> >> >
> >> >> >
> >> >> > well, to the extent that i think "pthreads that's also available
> on Windows" is useful to some, sure, i'll continue to add the trivial
> inline functions to bionic so that this is actually portable (
> https://android.googlesource.com/platform/bionic/+/master/libc/include/bits/threads_inlines.h).
> but for Android host tools themselves, i think we'll continue to use
> std::thread or pthreads via mingw.
> >> >> >
> >> >> > but my real feedback earlier was the same as what you're seeing
> here: "since this is a WG14-driven thing, it should come as a proposal from
> there first". anyone using bionic or glibc already has perfectly good
> pthread apis, so no real need for this stuff until/unless it's in Windows.
> (and last time i looked, Windows hadn't actually implemented the existing
> <threads.h> stuff yet?)
> >> >>
> >> >> Yeah, you are correct, windows msvc doesn't have either pthread or
> c11 threads, and pthreads is so huge, so there is multiple third-party c11
> threads implementation for MSVC, that's why I wanna c2y threads comes with
> monotonic mtx_timedlock cnd_timedwait support, so that the third-party c11
> threads implementation have a consistence API to implement.
> >> >
> >> >
> >> > if MS didn't bother to implement the C11 functions, why do you think
> they'd implement any future additions?
> >>
> >> I don't bother MS if they will implement the C11 functions, I just want
> a set of cross-platform threads api(c11 threads) to use (non-posix
> non-pthreads), we can always polyfill that API when the native libc doesn't
> support that.
> >> The API is more important than who would implement it
> >
> >
> > if you're the only person implementing it _and_ the only person using it
> ... it doesn't really matter what you call it? just put _something_ in your
> code, and worry about changing the name/signature if/when WG14 adds
> something equivalent.
>
> I am not the only person implementing it _and_ the only person using it
> obviously, I am just the only person that want to improve the c11 threads
> api currently
>

i thought you said you wanted this for mesa?


> >
> >>
> >> >
> >> >>
> >> >> So my question, anyone in this threads have suggestion about the
> newly proposed API:
> >> >>
> >> >>  int mtx_timedlock_base (mtx_t*, int, const struct timespec*);
> >> >>  int cnd_timedwait_base (cnd_t*, mtx_t*, int, const struct
> timespec*);
> >> >
> >> >
> >> > don't existing functions put the `int __base` last? sounds like a
> question for WG14 rather than c library implementors though --- as long as
> this isn't supported on the platform that doesn't have pthreads, it's not
> filling any obvious need.
> >> >
> >> >>
> >> >> >
> >> >> >>
> >> >> >> If we have minimal agreement about this proposal, I'd like to add
> tests for it. But still, I don't think
> >> >> >> __USE_GNU is a good name for it, because it's for C2y or C3x, any
> better option for this, so that it's not GNU restricted, for example,
> suppose MSVC also wants to implement this?
> >> >> >>
> >> >> >>
> >> >> >> >
> >> >> >> > > +extern int __REDIRECT (mtx_timedlock_base, (mtx_t
> *__restrict __mutex,
> >> >> >> > > +                                            int time_base,
> >> >> >> > > +                                            const struct
> timespec *__restrict
> >> >> >> > > +                                            __time_point),
> >> >> >> > > +                       __mtx_timedlock_base64);
> >> >> >> >
> >> >> >> > Likewise, should be conditional on __USE_GNU and time_base
> should be
> >> >> >> > __time_base.
> >> >> >> >
> >> >> >> > > +extern int cnd_timedwait_base (cnd_t *__restrict __cond,
> >> >> >> > > +                               mtx_t *__restrict __mutex,
> int time_base,
> >> >> >> > > +                               const struct timespec
> *__restrict __time_point);
> >> >> >> >
> >> >> >> > > +extern int __REDIRECT (cnd_timedwait_base, (cnd_t
> *__restrict __cond,
> >> >> >> > > +                                            mtx_t
> *__restrict __mutex,
> >> >> >> > > +                                            int time_base,
> >> >> >> > > +                                            const struct
> timespec *__restrict
> >> >> >> > > +                                            __time_point),
> >> >> >> >
> >> >> >> > Likewise.
> >> >> >> >
> >> >> >> > --
> >> >> >> > Joseph S. Myers
> >> >> >> > joseph@codesourcery.com
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >>          此致
> >> >> >> 礼
> >> >> >> 罗勇刚
> >> >> >> Yours
> >> >> >>     sincerely,
> >> >> >> Yonggang Luo
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >>          此致
> >> >> 礼
> >> >> 罗勇刚
> >> >> Yours
> >> >>     sincerely,
> >> >> Yonggang Luo
> >>
> >>
> >>
> >> --
> >>          此致
> >> 礼
> >> 罗勇刚
> >> Yours
> >>     sincerely,
> >> Yonggang Luo
>
>
>
> --
>          此致
> 礼
> 罗勇刚
> Yours
>     sincerely,
> Yonggang Luo
>
  

On Thu, Jun 22, 2023 at 3:18 AM enh <enh@google.com> wrote:
>
>
>
> On Wed, Jun 21, 2023 at 12:08 PM 罗勇刚(Yonggang Luo) <luoyonggang@gmail.com>
wrote:
>>
>>
>>
>> On Thu, Jun 22, 2023 at 3:05 AM enh <enh@google.com> wrote:
>> >
>> >
>> >
>> > On Wed, Jun 21, 2023 at 11:39 AM 罗勇刚(Yonggang Luo) <
luoyonggang@gmail.com> wrote:
>> >>
>> >>
>> >>
>> >> On Wed, Jun 21, 2023 at 10:31 PM enh <enh@google.com> wrote:
>> >> >
>> >> >
>> >> >
>> >> > On Wed, Jun 21, 2023 at 2:21 AM 罗勇刚(Yonggang Luo) <
luoyonggang@gmail.com> wrote:
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Wed, Jun 21, 2023 at 4:41 AM Joseph Myers <
joseph@codesourcery.com> wrote:
>> >> >> >
>> >> >> > On Wed, 21 Jun 2023, Yonggang Luo via Libc-alpha wrote:
>> >> >> >
>> >> >> > > diff --git a/sysdeps/pthread/threads.h
b/sysdeps/pthread/threads.h
>> >> >> > > index d88d7a3ddd..4f61ad9236 100644
>> >> >> > > --- a/sysdeps/pthread/threads.h
>> >> >> > > +++ b/sysdeps/pthread/threads.h
>> >> >> > > @@ -146,14 +146,22 @@ extern int mtx_lock (mtx_t *__mutex);
>> >> >> > >  #ifndef __USE_TIME_BITS64
>> >> >> > >  extern int mtx_timedlock (mtx_t *__restrict __mutex,
>> >> >> > >                         const struct timespec *__restrict
__time_point);
>> >> >> > > +extern int mtx_timedlock_base (mtx_t *__restrict __mutex, int
time_base,
>> >> >> > > +                               const struct timespec
*__restrict __time_point);
>> >> >> >
>> >> >> > As noted, this should be conditional on __USE_GNU.  Since you
didn't make
>> >> >> > it conditional, I'd expect it to have failed the conform/
namespace tests
>> >> >> > - both for the mtx_timedlock_base name itself if there weren't
incorrect
>> >> >> > conform/ changes in the patch series, and for the time_base
parameter
>> >> >> > (parameters in installed headers should always have a leading
__).  How
>> >> >> > did you test these patches?
>> >> >>
>> >> >> I am not testing these patches yet(as a new contributor for glibc,
don't know how to do that yet),
>> >> >> and for this patch, I'd like to know if the prototype of these two
functions is proper first
>> >> >>
>> >> >> int mtx_timedlock_base(mtx_t *restrict m, int time_base, const
struct timespec *restrict ts);
>> >> >>
>> >> >> int cnd_timedwait_base(cnd_t *restrict c, mtx_t *restrict m, int
time_base, const struct timespec *restrict ts);
>> >> >>
>> >> >> The function name was suggested by Jens Gustedt, and indeed I also
thought about this name in the first place(because posix has cond_clockwait
and mutex_clocklock already). And seems enh also like this
>> >> >
>> >> >
>> >> > well, to the extent that i think "pthreads that's also available on
Windows" is useful to some, sure, i'll continue to add the trivial inline
functions to bionic so that this is actually portable (
https://android.googlesource.com/platform/bionic/+/master/libc/include/bits/threads_inlines.h).
but for Android host tools themselves, i think we'll continue to use
std::thread or pthreads via mingw.
>> >> >
>> >> > but my real feedback earlier was the same as what you're seeing
here: "since this is a WG14-driven thing, it should come as a proposal from
there first". anyone using bionic or glibc already has perfectly good
pthread apis, so no real need for this stuff until/unless it's in Windows.
(and last time i looked, Windows hadn't actually implemented the existing
<threads.h> stuff yet?)
>> >>
>> >> Yeah, you are correct, windows msvc doesn't have either pthread or
c11 threads, and pthreads is so huge, so there is multiple third-party c11
threads implementation for MSVC, that's why I wanna c2y threads comes with
monotonic mtx_timedlock cnd_timedwait support, so that the third-party c11
threads implementation have a consistence API to implement.
>> >
>> >
>> > if MS didn't bother to implement the C11 functions, why do you think
they'd implement any future additions?
>>
>> I don't bother MS if they will implement the C11 functions, I just want
a set of cross-platform threads api(c11 threads) to use (non-posix
non-pthreads), we can always polyfill that API when the native libc doesn't
support that.
>> The API is more important than who would implement it
>
>
> if you're the only person implementing it _and_ the only person using it
... it doesn't really matter what you call it? just put _something_ in your
code, and worry about changing the name/signature if/when WG14 adds
something equivalent.
>
Think about a condition, support I want to use monotonic c11 threads
timedwait timedlock,
And I implemented it locally, then for glibc/bionic, I have to give it's
native implemented c11 threads, because those API doesn't support
monotonic timedwait timedlock, for platforms doesn't support c11 threads
anybody can implement a polyfill, that's not an issue, That's the reason
why I proposal this.

>>
>> >
>> >>
>> >> So my question, anyone in this threads have suggestion about the
newly proposed API:
>> >>
>> >>  int mtx_timedlock_base (mtx_t*, int, const struct timespec*);
>> >>  int cnd_timedwait_base (cnd_t*, mtx_t*, int, const struct timespec*);
>> >
>> >
>> > don't existing functions put the `int __base` last? sounds like a
question for WG14 rather than c library implementors though --- as long as
this isn't supported on the platform that doesn't have pthreads, it's not
filling any obvious need.
>> >
>> >>
>> >> >
>> >> >>
>> >> >> If we have minimal agreement about this proposal, I'd like to add
tests for it. But still, I don't think
>> >> >> __USE_GNU is a good name for it, because it's for C2y or C3x, any
better option for this, so that it's not GNU restricted, for example,
suppose MSVC also wants to implement this?
>> >> >>
>> >> >>
>> >> >> >
>> >> >> > > +extern int __REDIRECT (mtx_timedlock_base, (mtx_t *__restrict
__mutex,
>> >> >> > > +                                            int time_base,
>> >> >> > > +                                            const struct
timespec *__restrict
>> >> >> > > +                                            __time_point),
>> >> >> > > +                       __mtx_timedlock_base64);
>> >> >> >
>> >> >> > Likewise, should be conditional on __USE_GNU and time_base
should be
>> >> >> > __time_base.
>> >> >> >
>> >> >> > > +extern int cnd_timedwait_base (cnd_t *__restrict __cond,
>> >> >> > > +                               mtx_t *__restrict __mutex, int
time_base,
>> >> >> > > +                               const struct timespec
*__restrict __time_point);
>> >> >> >
>> >> >> > > +extern int __REDIRECT (cnd_timedwait_base, (cnd_t *__restrict
__cond,
>> >> >> > > +                                            mtx_t *__restrict
__mutex,
>> >> >> > > +                                            int time_base,
>> >> >> > > +                                            const struct
timespec *__restrict
>> >> >> > > +                                            __time_point),
>> >> >> >
>> >> >> > Likewise.
>> >> >> >
>> >> >> > --
>> >> >> > Joseph S. Myers
>> >> >> > joseph@codesourcery.com
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >>          此致
>> >> >> 礼
>> >> >> 罗勇刚
>> >> >> Yours
>> >> >>     sincerely,
>> >> >> Yonggang Luo
>> >>
>> >>
>> >>
>> >> --
>> >>          此致
>> >> 礼
>> >> 罗勇刚
>> >> Yours
>> >>     sincerely,
>> >> Yonggang Luo
>>
>>
>>
>> --
>>          此致
>> 礼
>> 罗勇刚
>> Yours
>>     sincerely,
>> Yonggang Luo



--
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo
  

> i thought you said you wanted this for mesa?

yeap, mesa is one of those,
for example https://github.com/tinycthread/tinycthread have 800 star, those
people using
timedwait timedlock with TIME_UTC is because the c11 threads only have this
API, not because they do not want the monotonic timedwait/timedlock

In most case monotonic won't affect by system time change(that's more
stable).

--
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo