[PATCH v2 0/4] c2y proposal add monotonicwait support for mtx and ctx

[PATCH v2 0/4] c2y proposal add monotonicwait support for mtx and ctx

[Yonggang Luo]

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.

Yonggang Luo (4):
  clang-format: should format with 2 space and do not usage tab
  time: Implement c23 timespec_get base
  c11: Switch to use pthread_mutex_clocklock and pthread_cond_clockwait
    to implement cnd and mtx lock and wait
  c2y: Add function cnd_timedwait_base and mtx_timedlock_base

 .clang-format                                 |   4 +-
 conform/data/threads.h-data                   |   2 +
 htl/Versions                                  |   5 +
 nptl/Versions                                 |   5 +
 sysdeps/pthread/Makefile                      |   2 +
 sysdeps/pthread/cnd_timedwait.c               |   8 +-
 .../{cnd_timedwait.c => cnd_timedwait_base.c} |  58 +++++-----
 sysdeps/pthread/mtx_timedlock.c               |   6 +-
 .../{mtx_timedlock.c => mtx_timedlock_base.c} |  56 +++++-----
 sysdeps/pthread/threads.h                     |  18 ++++
 sysdeps/unix/sysv/linux/Versions              |   6 ++
 sysdeps/unix/sysv/linux/cnd_timedwait.c       |   4 +-
 .../{cnd_timedwait.c => cnd_timedwait_base.c} |  24 +++--
 sysdeps/unix/sysv/linux/mtx_timedlock.c       |   4 +-
 .../{mtx_timedlock.c => mtx_timedlock_base.c} | 100 +++++++++---------
 sysdeps/unix/sysv/linux/thrd_priv.h           |  10 ++
 time/time.h                                   |  13 ++-
 time/timespec_get.c                           |  51 ++++++++-
 18 files changed, 240 insertions(+), 136 deletions(-)
 copy sysdeps/pthread/{cnd_timedwait.c => cnd_timedwait_base.c} (70%)
 copy sysdeps/pthread/{mtx_timedlock.c => mtx_timedlock_base.c} (75%)
 copy sysdeps/unix/sysv/linux/{cnd_timedwait.c => cnd_timedwait_base.c} (60%)
 copy sysdeps/unix/sysv/linux/{mtx_timedlock.c => mtx_timedlock_base.c} (60%)

-- 
2.39.0.windows.1

[PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab

[Yonggang Luo]

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
---
 .clang-format | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/.clang-format b/.clang-format
index 36c169e007..6e8ef236be 100644
--- a/.clang-format
+++ b/.clang-format
@@ -146,8 +146,8 @@ SpacesInParentheses: false
 SpacesInSquareBrackets: false
 SpaceBeforeSquareBrackets: false
 Standard:        Cpp03
-TabWidth:        8
-UseTab:          Always
+TabWidth:        2
+UseTab:          Never
 ForEachMacros:
   - 'FOR_EACH_IMPL'
   - 'list_for_each'
-- 
2.39.0.windows.1

Re: [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab

[Zack Weinberg]

On Tue, Jun 20, 2023, at 1:17 PM, Yonggang Luo via Libc-alpha wrote:
> -TabWidth:        8
> -UseTab:          Always
> +TabWidth:        2
> +UseTab:          Never ForEachMacros:

This is not right.  GNU style is two spaces per *indent level*, but you
*are* supposed to use hard tabs to compress all runs of 8*n spaces at
the beginning of a line, regardless of the semantics of the spaces (i.e.
unlike some other styles, it doesn't matter whether the spaces represent
nesting or alignment).  I *thought* this was documented somewhere in
https://www.gnu.org/prep/standards/html_node/ but I can't find it (but I
have personally been yelled at on this very mailing list for screwing it
up, so I don't want you to have the same experience).

Whether clang-format can do this correctly, I do not know.

zw

Re: [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab

[罗勇刚(Yonggang Luo)]

[-- Attachment #1: Type: text/plain, Size: 1272 bytes --]

On Wed, Jun 21, 2023 at 1:45 AM Zack Weinberg <zack@owlfolio.org> wrote:
>
> On Tue, Jun 20, 2023, at 1:17 PM, Yonggang Luo via Libc-alpha wrote:
> > -TabWidth:        8
> > -UseTab:          Always
> > +TabWidth:        2
> > +UseTab:          Never ForEachMacros:
>
> This is not right.  GNU style is two spaces per *indent level*, but you
> *are* supposed to use hard tabs to compress all runs of 8*n spaces at

I am trying to stop using Tab in the code base, so I don't understand
what's your
concern, before the patch, the clang-format tried to use an 8 spaces width
tab to  indent  code.
After this patch, the clang-patch always uses 2 spaces to indent code.

> the beginning of a line, regardless of the semantics of the spaces (i.e.
> unlike some other styles, it doesn't matter whether the spaces represent
> nesting or alignment).  I *thought* this was documented somewhere in
> https://www.gnu.org/prep/standards/html_node/ but I can't find it (but I
> have personally been yelled at on this very mailing list for screwing it
> up, so I don't want you to have the same experience).
>
> Whether clang-format can do this correctly, I do not know.
>
> zw



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

Re: [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab

[Xi Ruoyao]

On Wed, 2023-06-21 at 14:31 +0800, 罗勇刚(Yonggang Luo) via Libc-alpha wrote:
> On Wed, Jun 21, 2023 at 1:45 AM Zack Weinberg <zack@owlfolio.org> wrote:
> > 
> > On Tue, Jun 20, 2023, at 1:17 PM, Yonggang Luo via Libc-alpha wrote:
> > > -TabWidth:        8
> > > -UseTab:          Always
> > > +TabWidth:        2
> > > +UseTab:          Never ForEachMacros:
> > 
> > This is not right.  GNU style is two spaces per *indent level*, but you
> > *are* supposed to use hard tabs to compress all runs of 8*n spaces at
> 
> I am trying to stop using Tab in the code base, so I don't understand
> what's your
> concern, before the patch, the clang-format tried to use an 8 spaces width
> tab to  indent  code.
> After this patch, the clang-patch always uses 2 spaces to indent code.

Because the existing code uses one tab for 8 spaces.  Glibc has its own
coding standard, not "what you prefer".

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

Re: [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab

[罗勇刚(Yonggang Luo)]

[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]

On Wed, Jun 21, 2023 at 2:47 PM Xi Ruoyao <xry111@xry111.site> wrote:
>
> On Wed, 2023-06-21 at 14:31 +0800, 罗勇刚(Yonggang Luo) via Libc-alpha wrote:
> > On Wed, Jun 21, 2023 at 1:45 AM Zack Weinberg <zack@owlfolio.org> wrote:
> > >
> > > On Tue, Jun 20, 2023, at 1:17 PM, Yonggang Luo via Libc-alpha wrote:
> > > > -TabWidth:        8
> > > > -UseTab:          Always
> > > > +TabWidth:        2
> > > > +UseTab:          Never ForEachMacros:
> > >
> > > This is not right.  GNU style is two spaces per *indent level*, but
you
> > > *are* supposed to use hard tabs to compress all runs of 8*n spaces at
> >
> > I am trying to stop using Tab in the code base, so I don't understand
> > what's your
> > concern, before the patch, the clang-format tried to use an 8 spaces
width
> > tab to  indent  code.
> > After this patch, the clang-patch always uses 2 spaces to indent code.
>
> Because the existing code uses one tab for 8 spaces.  Glibc has its own
> coding standard, not "what you prefer".

I am also talking about the existing code, so the conclusion is the
existing code
is not consistent, some use one tab for 8 spaces, some use spaces directly

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



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

Re: [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab

[Xi Ruoyao]

On Wed, 2023-06-21 at 14:55 +0800, 罗勇刚(Yonggang Luo) wrote:
> > Because the existing code uses one tab for 8 spaces.  Glibc has its own
> > coding standard, not "what you prefer".
> 
> I am also talking about the existing code, so the conclusion is the existing code 
> is not consistent, some use one tab for 8 spaces, some use spaces directly

Anyway "TabWidth: 2" is wrong.  If you want to avoid tab at all, the
TabWidth setting is irrelevant and should be removed.

We already have "UseTab: Always" and "IndentWidth: 2", these matches the
description of Zack.  As the patch adding .clang-format had been
reviewed (the commit adding it even contains an R-b tag from Carlos), it
implies the current consensus for new code is to *always* tabs for 8
spaces.

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

Re: [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab

[罗勇刚(Yonggang Luo)]

[-- Attachment #1: Type: text/plain, Size: 1421 bytes --]

On Wed, Jun 21, 2023 at 3:13 PM Xi Ruoyao <xry111@xry111.site> wrote:
>
> On Wed, 2023-06-21 at 14:55 +0800, 罗勇刚(Yonggang Luo) wrote:
> > > Because the existing code uses one tab for 8 spaces.  Glibc has its
own
> > > coding standard, not "what you prefer".
> >
> > I am also talking about the existing code, so the conclusion is the
existing code
> > is not consistent, some use one tab for 8 spaces, some use spaces
directly
>
> Anyway "TabWidth: 2" is wrong.  If you want to avoid tab at all, the
> TabWidth setting is irrelevant and should be removed.
>
> We already have "UseTab: Always" and "IndentWidth: 2", these matches the
> description of Zack.  As the patch adding .clang-format had been
> reviewed (the commit adding it even contains an R-b tag from Carlos), it
> implies the current consensus for new code is to *always* tabs for 8
> spaces.
>
> --
> Xi Ruoyao <xry111@xry111.site>
> School of Aerospace Science and Technology, Xidian University

The output of clang-format --style=GNU -dump-config is:
```
StatementMacros:
  - Q_UNUSED
  - QT_REQUIRE_VERSION
TabWidth:        8
UseCRLF:         false
UseTab:          Never
WhitespaceSensitiveMacros:
  - STRINGIZE
  - PP_STRINGIZE
  - BOOST_PP_STRINGIZE
  - NS_SWIFT_NAME
  - CF_SWIFT_NAME
```
So yeah, UseTab: Never is enough.


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

Re: [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab

[Zack Weinberg]

On Wed, Jun 21, 2023, at 2:31 AM, 罗勇刚(Yonggang Luo) wrote:
> On Wed, Jun 21, 2023 at 1:45 AM Zack Weinberg <zack@owlfolio.org> wrote:
> > On Tue, Jun 20, 2023, at 1:17 PM, Yonggang Luo via Libc-alpha wrote:
> > > -TabWidth:        8
> > > -UseTab:          Always
> > > +TabWidth:        2
> > > +UseTab:          Never ForEachMacros:
> >
> > This is not right.  GNU style is two spaces per *indent level*, but you
> > *are* supposed to use hard tabs to compress all runs of 8*n spaces [...]
> 
> I am trying to stop using Tab in the code base

I sympathize with this goal, but you cannot make this change by yourself,
without any discussion or agreement -- and because the policy comes from
the GNU coding standards, you would need to have that discussion on the
GNU standards mailing list (https://lists.gnu.org/mailman/listinfo/bug-standards).
In my opinion, this particular change is very unlikely to be accepted
there, and I do not think the argument would be a good use of your time.
If you choose to try anyway, please *do not* cc the glibc development
list, me, or anyone else involved in this thread.

Please also understand that because glibc is very complicated and patches
are already difficult enough to review, we really need you to keep each
patch series narrowly focused on a single logical change.  Changes to
`.clang-format` should be submitted *independently* of patch series that
do anything else.

zw

Re: [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab

[Xi Ruoyao]

On Tue, 2023-06-20 at 13:45 -0400, Zack Weinberg via Libc-alpha wrote:
> I *thought* this was documented somewhere in
> https://www.gnu.org/prep/standards/html_node/ but I can't find it (but I
> have personally been yelled at on this very mailing list for screwing it
> up, so I don't want you to have the same experience).

It's implied by:

"""
The rest of this section gives our recommendations for other aspects of
C formatting style, which is also the default style of the indent
program in version 1.2 and newer. It corresponds to the options

-nbad -bap -nbc -bbo -bl -bli2 -bls -ncdb -nce -cp1 -cs -di2
-ndj -nfc1 -nfca -hnl -i2 -ip5 -lp -pcs -psl -nsc -nsob
"""

There is no -nut.

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

Re: [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab

[Carlos O'Donell]

On 6/20/23 13:45, Zack Weinberg via Libc-alpha wrote:
> On Tue, Jun 20, 2023, at 1:17 PM, Yonggang Luo via Libc-alpha wrote:
>> -TabWidth:        8
>> -UseTab:          Always
>> +TabWidth:        2
>> +UseTab:          Never ForEachMacros:
> 
> This is not right.  GNU style is two spaces per *indent level*, but you
> *are* supposed to use hard tabs to compress all runs of 8*n spaces at
> the beginning of a line, regardless of the semantics of the spaces (i.e.
> unlike some other styles, it doesn't matter whether the spaces represent
> nesting or alignment).  I *thought* this was documented somewhere in
> https://www.gnu.org/prep/standards/html_node/ but I can't find it (but I
> have personally been yelled at on this very mailing list for screwing it
> up, so I don't want you to have the same experience).

It would be complete unacceptable to yell at anyone in person or virtually in this
community for getting this wrong. We should be kind and sympathetic to developers
working on our project and provide them with the tools they need to avoid these
problems.

It is *my* failing as a steward for the project if we don't make this easy, and I
like clang-format because it makes this easy. I don't actually care what we pick
but we should as project pick something and make it easy to support developers.

-- 
Cheers,
Carlos.

Re: [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab

[Joseph Myers]

On Wed, 21 Jun 2023, Carlos O'Donell via Libc-alpha wrote:

> It is *my* failing as a steward for the project if we don't make this 
> easy, and I like clang-format because it makes this easy. I don't 
> actually care what we pick but we should as project pick something and 
> make it easy to support developers.

Personally I like not using tabs, but (a) the current glibc convention 
definitely uses tabs and (b) changes like that definitely don't belong in 
an unrelated patch series.

I don't think the convention of tabs for every eight columns is 
*documented* GNU style, it's more like "GNU style by default because it's 
what Emacs does by default" (you can stop Emacs doing it with an 
appropriate .dir-locals.el, but then you need to re-enable tabs in 
.dir-locals.el for makefile-mode and any other modes that should continue 
to use tabs).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab

[罗勇刚(Yonggang Luo)]

[-- Attachment #1: Type: text/plain, Size: 1369 bytes --]

On Thu, Jun 22, 2023 at 1:35 AM Joseph Myers <joseph@codesourcery.com>
wrote:
>
> On Wed, 21 Jun 2023, Carlos O'Donell via Libc-alpha wrote:
>
> > It is *my* failing as a steward for the project if we don't make this
> > easy, and I like clang-format because it makes this easy. I don't
> > actually care what we pick but we should as project pick something and
> > make it easy to support developers.
>
> Personally I like not using tabs, but (a) the current glibc convention
> definitely uses tabs and (b) changes like that definitely don't belong in
> an unrelated patch series.
>
> I don't think the convention of tabs for every eight columns is
> *documented* GNU style, it's more like "GNU style by default because it's
> what Emacs does by default" (you can stop Emacs doing it with an
> appropriate .dir-locals.el, but then you need to re-enable tabs in
> .dir-locals.el for makefile-mode and any other modes that should continue
> to use tabs).

clang-format --style=GNU -dump-config

show the default GNU style won't use tab, and Emacs is not the sole editor,
I am not using Emcas,
For other editors, 8 tab is rare, so when I am reading the glib code, the
indent mixed space/tab looks weird


>
> --
> Joseph S. Myers
> joseph@codesourcery.com



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

Re: [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab

[Andrew Pinski]

On Wed, Jun 21, 2023 at 10:42 AM 罗勇刚(Yonggang Luo) via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
> On Thu, Jun 22, 2023 at 1:35 AM Joseph Myers <joseph@codesourcery.com>
> wrote:
> >
> > On Wed, 21 Jun 2023, Carlos O'Donell via Libc-alpha wrote:
> >
> > > It is *my* failing as a steward for the project if we don't make this
> > > easy, and I like clang-format because it makes this easy. I don't
> > > actually care what we pick but we should as project pick something and
> > > make it easy to support developers.
> >
> > Personally I like not using tabs, but (a) the current glibc convention
> > definitely uses tabs and (b) changes like that definitely don't belong in
> > an unrelated patch series.
> >
> > I don't think the convention of tabs for every eight columns is
> > *documented* GNU style, it's more like "GNU style by default because it's
> > what Emacs does by default" (you can stop Emacs doing it with an
> > appropriate .dir-locals.el, but then you need to re-enable tabs in
> > .dir-locals.el for makefile-mode and any other modes that should continue
> > to use tabs).
>
> clang-format --style=GNU -dump-config
>
> show the default GNU style won't use tab, and Emacs is not the sole editor,
> I am not using Emcas,
> For other editors, 8 tab is rare, so when I am reading the glib code, the
> indent mixed space/tab looks weird

Note vi defaults to 8 spaces to a tab too.
I suspect the non-8 spaces are non-UNIX first editors. I know
notepad++ defaults to 4 spaces but I changed the settings there to 8
because I actually like 8 spaces to the tab idea; 4 seems too little.

Thanks,
Andrew Pinski

>
>
> >
> > --
> > Joseph S. Myers
> > joseph@codesourcery.com
>
>
>
> --
>          此致
> 礼
> 罗勇刚
> Yours
>     sincerely,
> Yonggang Luo

Re: [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab

[罗勇刚(Yonggang Luo)]

[-- Attachment #1: Type: text/plain, Size: 2230 bytes --]

On Thu, Jun 22, 2023 at 1:49 AM Andrew Pinski <pinskia@gmail.com> wrote:
>
> On Wed, Jun 21, 2023 at 10:42 AM 罗勇刚(Yonggang Luo) via Libc-alpha
> <libc-alpha@sourceware.org> wrote:
> >
> > On Thu, Jun 22, 2023 at 1:35 AM Joseph Myers <joseph@codesourcery.com>
> > wrote:
> > >
> > > On Wed, 21 Jun 2023, Carlos O'Donell via Libc-alpha wrote:
> > >
> > > > It is *my* failing as a steward for the project if we don't make
this
> > > > easy, and I like clang-format because it makes this easy. I don't
> > > > actually care what we pick but we should as project pick something
and
> > > > make it easy to support developers.
> > >
> > > Personally I like not using tabs, but (a) the current glibc convention
> > > definitely uses tabs and (b) changes like that definitely don't
belong in
> > > an unrelated patch series.
> > >
> > > I don't think the convention of tabs for every eight columns is
> > > *documented* GNU style, it's more like "GNU style by default because
it's
> > > what Emacs does by default" (you can stop Emacs doing it with an
> > > appropriate .dir-locals.el, but then you need to re-enable tabs in
> > > .dir-locals.el for makefile-mode and any other modes that should
continue
> > > to use tabs).
> >
> > clang-format --style=GNU -dump-config
> >
> > show the default GNU style won't use tab, and Emacs is not the sole
editor,
> > I am not using Emcas,
> > For other editors, 8 tab is rare, so when I am reading the glib code,
the
> > indent mixed space/tab looks weird
>
> Note vi defaults to 8 spaces to a tab too.
> I suspect the non-8 spaces are non-UNIX first editors. I know
> notepad++ defaults to 4 spaces but I changed the settings there to 8
> because I actually like 8 spaces to the tab idea; 4 seems too little.
That‘s why better always using space, so that different editor would show
it consistence
I am using vscode.


>
> Thanks,
> Andrew Pinski
>
> >
> >
> > >
> > > --
> > > Joseph S. Myers
> > > joseph@codesourcery.com
> >
> >
> >
> > --
> >          此致
> > 礼
> > 罗勇刚
> > Yours
> >     sincerely,
> > Yonggang Luo



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

Re: [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 927 bytes --]

罗勇刚(Yonggang Luo) via Libc-alpha <libc-alpha@sourceware.org> writes:

>> Note vi defaults to 8 spaces to a tab too.
>> I suspect the non-8 spaces are non-UNIX first editors. I know
>> notepad++ defaults to 4 spaces but I changed the settings there to 8
>> because I actually like 8 spaces to the tab idea; 4 seems too little.
> That‘s why better always using space, so that different editor would show
> it consistence
> I am using vscode.

I agree that in a code style based on spaces, 'compressing' eight spaces
to tabs makes little sense.

The current problem of 'editors configure tabs to a non-standard value
out of the box', however, might be solved by something like an
EditorConfig file, assuming it's not desirable to change the code style
to not compress tabs.

I'm not aware of anything other than EditorConfig that's even remotely
standard (or even cross-editor).
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab

[罗勇刚(Yonggang Luo)]

[-- Attachment #1: Type: text/plain, Size: 1310 bytes --]

On Thu, Jun 22, 2023 at 2:36 AM Arsen Arsenović <arsen@gentoo.org> wrote:
>
> 罗勇刚(Yonggang Luo) via Libc-alpha <libc-alpha@sourceware.org> writes:
>
> >> Note vi defaults to 8 spaces to a tab too.
> >> I suspect the non-8 spaces are non-UNIX first editors. I know
> >> notepad++ defaults to 4 spaces but I changed the settings there to 8
> >> because I actually like 8 spaces to the tab idea; 4 seems too little.
> > That‘s why better always using space, so that different editor would
show
> > it consistence
> > I am using vscode.
>
> I agree that in a code style based on spaces, 'compressing' eight spaces
> to tabs makes little sense.
>
> The current problem of 'editors configure tabs to a non-standard value
> out of the box', however, might be solved by something like an
> EditorConfig file, assuming it's not desirable to change the code style
> to not compress tabs.
>
> I'm not aware of anything other than EditorConfig that's even remotely
> standard (or even cross-editor).
> --
> Arsen Arsenović

Yeap, EditorConfig file is supported for multiple editors, but this
clang-format file
is hard to be supported by the editor:)
Because it's formatted result are mixed tab and space

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

Re: [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab

[Zack Weinberg]

On Wed, Jun 21, 2023, at 1:41 PM, 罗勇刚(Yonggang Luo) wrote:
> On Thu, Jun 22, 2023 at 1:35 AM Joseph Myers <joseph@codesourcery.com> wrote:
> >
> > On Wed, 21 Jun 2023, Carlos O'Donell via Libc-alpha wrote:
> >
> > > It is *my* failing as a steward for the project if we don't make this
> > > easy, and I like clang-format because it makes this easy. I don't
> > > actually care what we pick but we should as project pick something and
> > > make it easy to support developers.
> >
> > Personally I like not using tabs, but (a) the current glibc convention
> > definitely uses tabs and (b) changes like that definitely don't belong in
> > an unrelated patch series.
> >
> > I don't think the convention of tabs for every eight columns is
> > *documented* GNU style, it's more like "GNU style by default because it's
> > what Emacs does by default" (you can stop Emacs doing it with an
> > appropriate .dir-locals.el, but then you need to re-enable tabs in
> > .dir-locals.el for makefile-mode and any other modes that should continue
> > to use tabs).
> 
> clang-format --style=GNU -dump-config
> 
> show the default GNU style won't use tab

That's a bug in clang-format (which is not a GNU project).  For C, the correct
thing to take as the official style is the behavior of `indent -gnu`, and as
already pointed out upthread, that uses tabs as described.

...
> For other editors, 8 tab is rare

8 spaces per tab is not just the norm going back at *least* as far as the VT52,
it's the *only option* in a lot of contexts (e.g. I don't believe there is any
way to configure this at all in most terminal emulators).  Any editor that
defaults to anything else is, therefore, buggy.

zw

Re: [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab

[Paul Eggert]

On 2023-06-21 10:35, Joseph Myers wrote:
> I don't think the convention of tabs for every eight columns is
> *documented*  GNU style,

Actually, it's documented to be 8:

"Calculate column numbers assuming that space and all ASCII printing 
characters have equal width, and assuming tab stops every 8 columns."

https://www.gnu.org/prep/standards/html_node/Errors.html

Re: [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab

[Joseph Myers]

On Wed, 21 Jun 2023, Paul Eggert wrote:

> On 2023-06-21 10:35, Joseph Myers wrote:
> > I don't think the convention of tabs for every eight columns is
> > *documented*  GNU style,
> 
> Actually, it's documented to be 8:
> 
> "Calculate column numbers assuming that space and all ASCII printing
> characters have equal width, and assuming tab stops every 8 columns."
> 
> https://www.gnu.org/prep/standards/html_node/Errors.html

I think that's about a documented convention for *reading* files - not a 
convention that when *writing* C source files you use tabs rather than 
spaces for a multiple of 8 leading blank columns.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab

[Paul Eggert]

On 2023-06-22 14:43, Joseph Myers wrote:
>> On 2023-06-21 10:35, Joseph Myers wrote:
>>> I don't think the convention of tabs for every eight columns is
>>> *documented*   GNU style,
>> Actually, it's documented to be 8:
>>
>> "Calculate column numbers assuming that space and all ASCII printing
>> characters have equal width, and assuming tab stops every 8 columns."
>>
>> https://www.gnu.org/prep/standards/html_node/Errors.html
> I think that's about a documented convention for*reading*  files - not a
> convention that when*writing*  C source files you use tabs rather than
> spaces for a multiple of 8 leading blank columns.

You're right that it doesn't say you must use tabs in source code. But 
if you use tabs, tab stops should be every 8 columns, not every 4 (or 
some other number). Otherwise the guideline makes no sense.

I thought your point was about the "eight columns"; if it was something 
else then please never mind.

[PATCH v2 2/4] time: Implement c23 timespec_get base

[Yonggang Luo]

These are implemented https://gustedt.gitlabpages.inria.fr/c23-library/#time_monotonic-time_active-time_thread_active

with:

# define TIME_MONOTONIC          2
# define TIME_ACTIVE             3
# define TIME_THREAD_ACTIVE      4
# define TIME_MONOTONIC_RAW      5
# define TIME_UTC_COARSE         6
# define TIME_MONOTONIC_COARSE   7
# define TIME_BOOTTIME           8
# define TIME_UTC_ALARM          9
# define TIME_BOOTTIME_ALARM     10
# define TIME_SGI_CYCLE          11
# define TIME_TAI                12

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
---
 time/time.h         | 13 +++++++++++-
 time/timespec_get.c | 51 +++++++++++++++++++++++++++++++++++++++++----
 2 files changed, 59 insertions(+), 5 deletions(-)

diff --git a/time/time.h b/time/time.h
index 368f4dc588..660cbb200b 100644
--- a/time/time.h
+++ b/time/time.h
@@ -62,7 +62,18 @@ typedef __pid_t pid_t;
 
 #ifdef __USE_ISOC11
 /* Time base values for timespec_get.  */
-# define TIME_UTC 1
+# define TIME_UTC                1
+# define TIME_MONOTONIC          2
+# define TIME_ACTIVE             3
+# define TIME_THREAD_ACTIVE      4
+# define TIME_MONOTONIC_RAW      5
+# define TIME_UTC_COARSE         6
+# define TIME_MONOTONIC_COARSE   7
+# define TIME_BOOTTIME           8
+# define TIME_UTC_ALARM          9
+# define TIME_BOOTTIME_ALARM     10
+# define TIME_SGI_CYCLE          11
+# define TIME_TAI                12
 #endif
 
 __BEGIN_DECLS
diff --git a/time/timespec_get.c b/time/timespec_get.c
index 9b1d4f22ed..20c0e4d9aa 100644
--- a/time/timespec_get.c
+++ b/time/timespec_get.c
@@ -17,15 +17,58 @@
 
 #include <time.h>
 
-
 /* Set TS to calendar time based in time base BASE.  */
 int
 timespec_get (struct timespec *ts, int base)
 {
-  if (base == TIME_UTC)
+  clockid_t clockid = -1;
+  switch (base)
+    {
+    default:
+      break;
+    case TIME_UTC:
+      clockid = CLOCK_REALTIME;
+      break;
+    case TIME_MONOTONIC:
+      clockid = CLOCK_MONOTONIC;
+      break;
+    case TIME_ACTIVE:
+      clockid = CLOCK_PROCESS_CPUTIME_ID;
+      break;
+    case TIME_THREAD_ACTIVE:
+      clockid = CLOCK_THREAD_CPUTIME_ID;
+      break;
+    case TIME_MONOTONIC_RAW:
+      clockid = CLOCK_MONOTONIC_RAW;
+      break;
+    case TIME_UTC_COARSE:
+      clockid = CLOCK_REALTIME_COARSE;
+      break;
+    case TIME_MONOTONIC_COARSE:
+      clockid = CLOCK_MONOTONIC_COARSE;
+      break;
+    case TIME_BOOTTIME:
+      clockid = CLOCK_BOOTTIME;
+      break;
+    case TIME_UTC_ALARM:
+      clockid = CLOCK_REALTIME_ALARM;
+      break;
+    case TIME_BOOTTIME_ALARM:
+      clockid = CLOCK_BOOTTIME_ALARM;
+      break;
+    case TIME_SGI_CYCLE:
+      clockid = CLOCK_SGI_CYCLE;
+      break;
+    case TIME_TAI:
+      clockid = CLOCK_TAI;
+      break;
+    }
+  if (clockid >= 0)
     {
-      __clock_gettime (CLOCK_REALTIME, ts);
-      return base;
+      if (__clock_gettime (clockid, ts) >= 0)
+        {
+          return base;
+        }
     }
   return 0;
 }
-- 
2.39.0.windows.1

Re: [PATCH v2 2/4] time: Implement c23 timespec_get base

[Joseph Myers]

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

>  #ifdef __USE_ISOC11
>  /* Time base values for timespec_get.  */
> -# define TIME_UTC 1
> +# define TIME_UTC                1

> +# define TIME_MONOTONIC          2
> +# define TIME_ACTIVE             3
> +# define TIME_THREAD_ACTIVE      4

These should be conditional on C2x.

> +# define TIME_MONOTONIC_RAW      5
> +# define TIME_UTC_COARSE         6
> +# define TIME_MONOTONIC_COARSE   7
> +# define TIME_BOOTTIME           8
> +# define TIME_UTC_ALARM          9
> +# define TIME_BOOTTIME_ALARM     10
> +# define TIME_SGI_CYCLE          11
> +# define TIME_TAI                12

And adding these is questionable; certainly any extension to these 
interfaces would need properly documenting (i.e. with what glibc defines 
the semantics to be, *not* what the Linux kernel defines some CLOCK_* 
semantics to be), and if added, it would be appropriate for them to be 
conditional on __USE_GNU.

> +    case TIME_BOOTTIME:
> +      clockid = CLOCK_BOOTTIME;
> +      break;
> +    case TIME_UTC_ALARM:
> +      clockid = CLOCK_REALTIME_ALARM;
> +      break;
> +    case TIME_BOOTTIME_ALARM:
> +      clockid = CLOCK_BOOTTIME_ALARM;
> +      break;

These don't exist in bits/time.h; try building for Hurd with 
build-many-glibcs.py.

> +    case TIME_SGI_CYCLE:
> +      clockid = CLOCK_SGI_CYCLE;
> +      break;

And this doesn't exist in glibc at all.  Is a Linux kernel uapi header 
included somehow?

> +    case TIME_TAI:
> +      clockid = CLOCK_TAI;
> +      break;

Again, I'd expect this to break the build for Hurd.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH v2 2/4] time: Implement c23 timespec_get base

[罗勇刚(Yonggang Luo)]

[-- Attachment #1: Type: text/plain, Size: 3603 bytes --]

On Wed, Jun 21, 2023 at 4:37 AM Joseph Myers <joseph@codesourcery.com>
wrote:
>
> On Wed, 21 Jun 2023, Yonggang Luo via Libc-alpha wrote:
>
> >  #ifdef __USE_ISOC11
> >  /* Time base values for timespec_get.  */
> > -# define TIME_UTC 1
> > +# define TIME_UTC                1
>
> > +# define TIME_MONOTONIC          2
> > +# define TIME_ACTIVE             3
> > +# define TIME_THREAD_ACTIVE      4
>
> These should be conditional on C2x.
>
> > +# define TIME_MONOTONIC_RAW      5
> > +# define TIME_UTC_COARSE         6
> > +# define TIME_MONOTONIC_COARSE   7
> > +# define TIME_BOOTTIME           8
> > +# define TIME_UTC_ALARM          9
> > +# define TIME_BOOTTIME_ALARM     10
> > +# define TIME_SGI_CYCLE          11
> > +# define TIME_TAI                12
>
> And adding these is questionable; certainly any extension to these
> interfaces would need properly documenting (i.e. with what glibc defines
> the semantics to be, *not* what the Linux kernel defines some CLOCK_*
> semantics to be), and if added, it would be appropriate for them to be
> conditional on __USE_GNU.

Defining it without __USE_GNU is my intention, as TIME_* is not GNU
specified.
my intention is defines these TIME_* macros in a cross-platform manner, so
that
We can always accessed to these enums and have no need concern which
os/platform we are on,
and if the platform doesn't support that, we can use timespec_get(ts,
 TIME_TAI) !=  TIME_TAI
to do that. This is also why c11 introduced timespec_get.

>
> > +    case TIME_BOOTTIME:
> > +      clockid = CLOCK_BOOTTIME;
> > +      break;
> > +    case TIME_UTC_ALARM:
> > +      clockid = CLOCK_REALTIME_ALARM;
> > +      break;
> > +    case TIME_BOOTTIME_ALARM:
> > +      clockid = CLOCK_BOOTTIME_ALARM;
> > +      break;
>
> These don't exist in bits/time.h; try building for Hurd with
> build-many-glibcs.py.
>
> > +    case TIME_SGI_CYCLE:
> > +      clockid = CLOCK_SGI_CYCLE;
> > +      break;
>
> And this doesn't exist in glibc at all.  Is a Linux kernel uapi header
> included somehow?
>
> > +    case TIME_TAI:
> > +      clockid = CLOCK_TAI;
> > +      break;
>
> Again, I'd expect this to break the build for Hurd.
>

How about change the code to the form like this:
  clockid_t clockid = -1;
  switch (base)
    {
    default:
      break;
    case TIME_UTC:
      clockid = CLOCK_REALTIME;
      break;
    case TIME_MONOTONIC:
      clockid = CLOCK_MONOTONIC;
      break;
    case TIME_ACTIVE:
      clockid = CLOCK_PROCESS_CPUTIME_ID;
      break;
    case TIME_THREAD_ACTIVE:
      clockid = CLOCK_THREAD_CPUTIME_ID;
      break;
    case TIME_MONOTONIC_RAW:
      clockid = CLOCK_MONOTONIC_RAW;
      break;
    case TIME_UTC_COARSE:
      clockid = CLOCK_REALTIME_COARSE;
      break;
    case TIME_MONOTONIC_COARSE:
      clockid = CLOCK_MONOTONIC_COARSE;
      break;
#ifdef CLOCK_BOOTTIME
    case TIME_BOOTTIME:
      clockid = CLOCK_BOOTTIME;
      break;
#endif
#ifdef CLOCK_REALTIME_ALARM
    case TIME_UTC_ALARM:
      clockid = CLOCK_REALTIME_ALARM;
      break;
#endif
#ifdef CLOCK_BOOTTIME_ALARM
    case TIME_BOOTTIME_ALARM:
      clockid = CLOCK_BOOTTIME_ALARM;
      break;
#endif
#ifdef CLOCK_SGI_CYCLE
    case TIME_SGI_CYCLE:
      clockid = CLOCK_SGI_CYCLE;
      break;
#endif
#ifdef CLOCK_TAI
    case TIME_TAI:
      clockid = CLOCK_TAI;
      break;
#endif
    }


> --
> Joseph S. Myers
> joseph@codesourcery.com



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

[PATCH v2 3/4] c11: Switch to use pthread_mutex_clocklock and pthread_cond_clockwait to implement cnd and mtx lock and wait

[Yonggang Luo]

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
---
 sysdeps/pthread/cnd_timedwait.c         | 8 ++++----
 sysdeps/pthread/mtx_timedlock.c         | 6 +++---
 sysdeps/unix/sysv/linux/cnd_timedwait.c | 4 ++--
 sysdeps/unix/sysv/linux/mtx_timedlock.c | 4 ++--
 4 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/sysdeps/pthread/cnd_timedwait.c b/sysdeps/pthread/cnd_timedwait.c
index 25df50cb3a..ea2921a35c 100644
--- a/sysdeps/pthread/cnd_timedwait.c
+++ b/sysdeps/pthread/cnd_timedwait.c
@@ -20,10 +20,10 @@
 
 int
 cnd_timedwait (cnd_t *restrict cond, mtx_t *restrict mutex,
-	       const struct timespec* restrict time_point)
+               const struct timespec *restrict time_point)
 {
-  int err_code = __pthread_cond_timedwait ((pthread_cond_t *) cond,
-					   (pthread_mutex_t *) mutex,
-					   time_point);
+  int err_code = __pthread_cond_clockwait ((pthread_cond_t *) cond,
+                                           (pthread_mutex_t *) mutex,
+                                           CLOCK_REALTIME, time_point);
   return thrd_err_map (err_code);
 }
diff --git a/sysdeps/pthread/mtx_timedlock.c b/sysdeps/pthread/mtx_timedlock.c
index a3d236f3e1..77ab39a72c 100644
--- a/sysdeps/pthread/mtx_timedlock.c
+++ b/sysdeps/pthread/mtx_timedlock.c
@@ -20,9 +20,9 @@
 
 int
 mtx_timedlock (mtx_t *restrict mutex,
-	       const struct timespec *restrict time_point)
+               const struct timespec *restrict time_point)
 {
-  int err_code = __pthread_mutex_timedlock ((pthread_mutex_t *)mutex,
-					    time_point);
+  int err_code = __pthread_mutex_clocklock ((pthread_mutex_t *) mutex,
+                                            CLOCK_REALTIME, time_point);
   return thrd_err_map (err_code);
 }
diff --git a/sysdeps/unix/sysv/linux/cnd_timedwait.c b/sysdeps/unix/sysv/linux/cnd_timedwait.c
index 9fa6d71d1a..c612d4f94d 100644
--- a/sysdeps/unix/sysv/linux/cnd_timedwait.c
+++ b/sysdeps/unix/sysv/linux/cnd_timedwait.c
@@ -24,9 +24,9 @@ int
 __cnd_timedwait64 (cnd_t *restrict cond, mtx_t *restrict mutex,
                    const struct __timespec64 *restrict time_point)
 {
-  int err_code = __pthread_cond_timedwait64 ((pthread_cond_t *) cond,
+  int err_code = __pthread_cond_clockwait64 ((pthread_cond_t *) cond,
                                              (pthread_mutex_t *) mutex,
-                                             time_point);
+                                             CLOCK_REALTIME, time_point);
   return thrd_err_map (err_code);
 }
 
diff --git a/sysdeps/unix/sysv/linux/mtx_timedlock.c b/sysdeps/unix/sysv/linux/mtx_timedlock.c
index 8019792868..b8f6d51940 100644
--- a/sysdeps/unix/sysv/linux/mtx_timedlock.c
+++ b/sysdeps/unix/sysv/linux/mtx_timedlock.c
@@ -24,8 +24,8 @@ int
 __mtx_timedlock64 (mtx_t *restrict mutex,
                    const struct __timespec64 *restrict time_point)
 {
-  int err_code = __pthread_mutex_timedlock64 ((pthread_mutex_t *)mutex,
-                                              time_point);
+  int err_code = __pthread_mutex_clocklock64 ((pthread_mutex_t *) mutex,
+                                              CLOCK_REALTIME, time_point);
   return thrd_err_map (err_code);
 }
 
-- 
2.39.0.windows.1

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

[Yonggang Luo]

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

diff --git a/conform/data/threads.h-data b/conform/data/threads.h-data
index 406e497726..e938e0512c 100644
--- a/conform/data/threads.h-data
+++ b/conform/data/threads.h-data
@@ -34,6 +34,7 @@ function void thrd_yield (void)
 function int mtx_init (mtx_t*, int)
 function int mtx_lock (mtx_t*)
 function int mtx_timedlock (mtx_t*, const struct timespec*)
+function int mtx_timedlock_base (mtx_t*, int, const struct timespec*)
 function int mtx_trylock (mtx_t*)
 function int mtx_unlock (mtx_t*)
 function void mtx_destroy (mtx_t*)
@@ -45,6 +46,7 @@ function int cnd_signal (cnd_t*)
 function int cnd_broadcast (cnd_t*)
 function int cnd_wait (cnd_t*, mtx_t*)
 function int cnd_timedwait (cnd_t*, mtx_t*, const struct timespec*)
+function int cnd_timedwait_base (cnd_t*, mtx_t*, int, const struct timespec*)
 function void cnd_destroy (cnd_t*)
 
 function int tss_create (tss_t*, tss_dtor_t)
diff --git a/htl/Versions b/htl/Versions
index 70fa44631a..804005bfb9 100644
--- a/htl/Versions
+++ b/htl/Versions
@@ -170,6 +170,11 @@ libpthread {
     sem_clockwait;
   }
 
+  GLIBC_2.38 {
+    cnd_timedwait_base;
+    mtx_timedlock_base;
+  }
+
   GLIBC_PRIVATE {
     __pthread_initialize_minimal;
 
diff --git a/nptl/Versions b/nptl/Versions
index 3221de89d1..d44ab2b12d 100644
--- a/nptl/Versions
+++ b/nptl/Versions
@@ -525,6 +525,11 @@ libpthread {
   GLIBC_2.31 {
     __libpthread_version_placeholder;
   }
+
+  GLIBC_2.38 {
+    cnd_timedwait_base;
+    mtx_timedlock_base;
+  }
 }
 
 ld {
diff --git a/sysdeps/pthread/Makefile b/sysdeps/pthread/Makefile
index 32cf4eb119..a4a9d1b2cc 100644
--- a/sysdeps/pthread/Makefile
+++ b/sysdeps/pthread/Makefile
@@ -40,11 +40,13 @@ $(libpthread-routines-var) += \
   cnd_init \
   cnd_signal \
   cnd_timedwait \
+  cnd_timedwait_base \
   cnd_wait \
   mtx_destroy \
   mtx_init \
   mtx_lock \
   mtx_timedlock \
+  mtx_timedlock_base \
   mtx_trylock \
   mtx_unlock \
   pthread_atfork_compat \
diff --git a/sysdeps/pthread/cnd_timedwait_base.c b/sysdeps/pthread/cnd_timedwait_base.c
new file mode 100644
index 0000000000..e9be66ca0e
--- /dev/null
+++ b/sysdeps/pthread/cnd_timedwait_base.c
@@ -0,0 +1,29 @@
+/* C11 threads conditional timed wait implementation.
+   Copyright (C) 2018-2023 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, see
+   <https://www.gnu.org/licenses/>.  */
+
+#include "thrd_priv.h"
+
+int
+cnd_timedwait_base (cnd_t *restrict cond, mtx_t *restrict mutex, int time_base,
+                    const struct timespec *restrict time_point)
+{
+  int err_code = __pthread_cond_clockwait ((pthread_cond_t *) cond,
+                                           (pthread_mutex_t *) mutex,
+                                           time_base, time_point);
+  return thrd_err_map (err_code);
+}
diff --git a/sysdeps/pthread/mtx_timedlock_base.c b/sysdeps/pthread/mtx_timedlock_base.c
new file mode 100644
index 0000000000..9aecf84440
--- /dev/null
+++ b/sysdeps/pthread/mtx_timedlock_base.c
@@ -0,0 +1,28 @@
+/* C11 threads mutex timed lock implementation.
+   Copyright (C) 2018-2023 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, see
+   <https://www.gnu.org/licenses/>.  */
+
+#include "thrd_priv.h"
+
+int
+mtx_timedlock_base (mtx_t *restrict mutex, int time_base,
+                    const struct timespec *restrict time_point)
+{
+  int err_code = __pthread_mutex_clocklock ((pthread_mutex_t *) mutex,
+                                            time_base, time_point);
+  return thrd_err_map (err_code);
+}
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);
 #else
 # ifdef __REDIRECT
 extern int __REDIRECT (mtx_timedlock, (mtx_t *__restrict __mutex,
                                        const struct timespec *__restrict
                                        __time_point),
                        __mtx_timedlock64);
+extern int __REDIRECT (mtx_timedlock_base, (mtx_t *__restrict __mutex,
+                                            int time_base,
+                                            const struct timespec *__restrict
+                                            __time_point),
+                       __mtx_timedlock_base64);
 # else
 #  define mtx_timedlock __mtx_timedlock64
+#  define mtx_timedlock_base __mtx_timedlock_base64
 # endif
 #endif
 
@@ -198,6 +206,9 @@ extern int cnd_wait (cnd_t *__cond, mtx_t *__mutex);
 extern int cnd_timedwait (cnd_t *__restrict __cond,
 			  mtx_t *__restrict __mutex,
 			  const struct timespec *__restrict __time_point);
+extern int cnd_timedwait_base (cnd_t *__restrict __cond,
+                               mtx_t *__restrict __mutex, int time_base,
+                               const struct timespec *__restrict __time_point);
 #else
 # ifdef __REDIRECT
 extern int __REDIRECT (cnd_timedwait, (cnd_t *__restrict __cond,
@@ -205,8 +216,15 @@ extern int __REDIRECT (cnd_timedwait, (cnd_t *__restrict __cond,
                                        const struct timespec *__restrict
                                        __time_point),
                        __cnd_timedwait64);
+extern int __REDIRECT (cnd_timedwait_base, (cnd_t *__restrict __cond,
+                                            mtx_t *__restrict __mutex,
+                                            int time_base,
+                                            const struct timespec *__restrict
+                                            __time_point),
+                       __cnd_timedwait_base64);
 # else
 #  define cnd_timedwait __cnd_timedwait64
+#  define cnd_timedwait_base __cnd_timedwait_base64
 # endif
 #endif
 
diff --git a/sysdeps/unix/sysv/linux/Versions b/sysdeps/unix/sysv/linux/Versions
index bc59bce42f..73ce24bea6 100644
--- a/sysdeps/unix/sysv/linux/Versions
+++ b/sysdeps/unix/sysv/linux/Versions
@@ -319,6 +319,12 @@ libc {
   GLIBC_2.37 {
 %ifdef TIME64_NON_DEFAULT
     __ppoll64_chk;
+%endif
+  }
+  GLIBC_2.38 {
+%ifdef TIME64_NON_DEFAULT
+    __cnd_timedwait_base64;
+    __mtx_timedlock_base64;
 %endif
   }
   GLIBC_PRIVATE {
diff --git a/sysdeps/unix/sysv/linux/cnd_timedwait_base.c b/sysdeps/unix/sysv/linux/cnd_timedwait_base.c
new file mode 100644
index 0000000000..2e851a7aec
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/cnd_timedwait_base.c
@@ -0,0 +1,53 @@
+/* C11 threads conditional timed wait implementation - Linux variant.
+   Copyright (C) 2020-2023 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, see
+   <https://www.gnu.org/licenses/>.  */
+
+#include <time.h>
+#include <shlib-compat.h>
+#include "thrd_priv.h"
+
+int
+__cnd_timedwait_base64 (cnd_t *restrict cond, mtx_t *restrict mutex,
+                        int time_base,
+                        const struct __timespec64 *restrict time_point)
+{
+  int err_code = __pthread_cond_clockwait64 ((pthread_cond_t *) cond,
+                                             (pthread_mutex_t *) mutex,
+                                             time_base, time_point);
+  return thrd_err_map (err_code);
+}
+
+#if __TIMESIZE == 64
+strong_alias (__cnd_timedwait_base64, ___cnd_timedwait_base)
+#else
+libc_hidden_def (__cnd_timedwait_base64)
+
+int
+___cnd_timedwait_base (cnd_t *restrict cond, mtx_t *restrict mutex,
+                       int time_base,
+                       const struct timespec *restrict time_point)
+{
+  struct __timespec64 ts64 = valid_timespec_to_timespec64 (*time_point);
+
+  return __cnd_timedwait_base64 (cond, mutex, time_base, &ts64);
+}
+#endif /* __TIMESIZE == 64 */
+versioned_symbol (libc, ___cnd_timedwait_base, cnd_timedwait_base, GLIBC_2_34);
+
+#if OTHER_SHLIB_COMPAT (libpthread, GLIBC_2_28, GLIBC_2_34)
+compat_symbol (libpthread, ___cnd_timedwait_base, cnd_timedwait_base, GLIBC_2_28);
+#endif
diff --git a/sysdeps/unix/sysv/linux/mtx_timedlock_base.c b/sysdeps/unix/sysv/linux/mtx_timedlock_base.c
new file mode 100644
index 0000000000..046fb86091
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/mtx_timedlock_base.c
@@ -0,0 +1,50 @@
+/* C11 threads mutex timed lock implementation - Linux variant.
+   Copyright (C) 2020-2023 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, see
+   <https://www.gnu.org/licenses/>.  */
+
+#include <time.h>
+#include <shlib-compat.h>
+#include "thrd_priv.h"
+
+int
+__mtx_timedlock_base64 (mtx_t *restrict mutex, int time_base,
+                        const struct __timespec64 *restrict time_point)
+{
+  int err_code = __pthread_mutex_clocklock64 ((pthread_mutex_t *) mutex,
+                                              time_base, time_point);
+  return thrd_err_map (err_code);
+}
+
+#if __TIMESIZE == 64
+strong_alias (__mtx_timedlock_base64, ___mtx_timedlock_base)
+#else
+libc_hidden_def (__mtx_timedlock_base64)
+
+int
+___mtx_timedlock_base (mtx_t *restrict mutex, int time_base,
+                       const struct timespec *restrict time_point)
+{
+  struct __timespec64 ts64 = valid_timespec_to_timespec64 (*time_point);
+
+  return __mtx_timedlock_base64 (mutex, time_base, &ts64);
+}
+#endif /* __TIMESIZE == 64 */
+versioned_symbol (libc, ___mtx_timedlock_base, mtx_timedlock_base, GLIBC_2_34);
+
+#if OTHER_SHLIB_COMPAT (libpthread, GLIBC_2_28, GLIBC_2_34)
+compat_symbol (libpthread, ___mtx_timedlock_base, mtx_timedlock_base, GLIBC_2_28);
+#endif
diff --git a/sysdeps/unix/sysv/linux/thrd_priv.h b/sysdeps/unix/sysv/linux/thrd_priv.h
index af23a10a07..8ea9ced507 100644
--- a/sysdeps/unix/sysv/linux/thrd_priv.h
+++ b/sysdeps/unix/sysv/linux/thrd_priv.h
@@ -20,15 +20,25 @@
 
 #if __TIMESIZE == 64
 # define __cnd_timedwait64 __cnd_timedwait
+# define __cnd_timedwait_base64 __cnd_timedwait_base
 # define __mtx_timedlock64 __mtx_timedlock
+# define __mtx_timedlock_base64 __mtx_timedlock_base
 # define __thrd_sleep64 __thrd_sleep
 #else
 extern int __cnd_timedwait64 (cnd_t *restrict cond, mtx_t *restrict mutex,
                               const struct __timespec64 *restrict time_point);
 libc_hidden_proto (__cnd_timedwait64)
+extern int __cnd_timedwait_base64 (cnd_t *restrict cond, mtx_t *restrict mutex,
+                                   int time_base,
+                                   const struct __timespec64 *restrict time_point);
+libc_hidden_proto (__cnd_timedwait_base64)
 extern int __mtx_timedlock64 (mtx_t *restrict mutex,
                               const struct __timespec64 *restrict time_point);
 libc_hidden_proto (__mtx_timedlock64)
+extern int __mtx_timedlock_base64 (mtx_t *restrict mutex, int time_base,
+                                   const struct __timespec64 *restrict
+                                   time_point);
+libc_hidden_proto (__mtx_timedlock_base64)
 extern int __thrd_sleep64 (const struct __timespec64 *time_point,
                            struct __timespec64 *remaining);
 libc_hidden_proto (__thrd_sleep64)
-- 
2.39.0.windows.1

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

[Joseph Myers]

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.

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[罗勇刚(Yonggang Luo)]

[-- Attachment #1: Type: text/plain, Size: 3257 bytes --]

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

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

[Xi Ruoyao]

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>
School of Aerospace Science and Technology, Xidian University

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

[罗勇刚(Yonggang Luo)]

[-- Attachment #1: Type: text/plain, Size: 1942 bytes --]

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
>

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

[Xi Ruoyao]

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.

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

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

[Florian Weimer]

* 罗勇刚(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

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

[Jₑₙₛ Gustedt]

[-- Attachment #1: Type: text/plain, Size: 2340 bytes --]

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.

-- 
:: ICube :::::::::::::::::::::::::::::: deputy director ::
:: Université de Strasbourg :::::::::::::::::::::: ICPS ::
:: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus ::
:: :::::::::::::::::::::::::::::::::::: ☎ +33 368854536 ::
:: https://icube-icps.unistra.fr/index.php/Jens_Gustedt ::

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Joseph Myers]

[-- Attachment #1: Type: text/plain, Size: 1758 bytes --]

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).

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[enh]

[-- Attachment #1: Type: text/plain, Size: 4325 bytes --]

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
>

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

[Joseph Myers]

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.

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[罗勇刚(Yonggang Luo)]

[-- Attachment #1: Type: text/plain, Size: 5119 bytes --]

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

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

[enh]

[-- Attachment #1: Type: text/plain, Size: 5866 bytes --]

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
>

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

[罗勇刚(Yonggang Luo)]

[-- Attachment #1: Type: text/plain, Size: 6347 bytes --]

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

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

[enh]

[-- Attachment #1: Type: text/plain, Size: 7065 bytes --]

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
>

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

[罗勇刚(Yonggang Luo)]

[-- Attachment #1: Type: text/plain, Size: 7422 bytes --]

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

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

[enh]

[-- Attachment #1: Type: text/plain, Size: 8004 bytes --]

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
>

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

[罗勇刚(Yonggang Luo)]

[-- Attachment #1: Type: text/plain, Size: 475 bytes --]

> 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

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

[罗勇刚(Yonggang Luo)]

[-- Attachment #1: Type: text/plain, Size: 7660 bytes --]

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

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

[Joseph Myers]

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.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH v2 0/4] c2y proposal add monotonicwait support for mtx and ctx

[Joseph Myers]

I think it's a misrepresentation to refer to this as a C2y proposal.  
You're proposing a new GNU interface and should describe it as such and 
justify it as such.  Maybe you intend to propose it for C2y or C3x 
(whatever the next C standard revision is - we haven't decided on a 
schedule and that's not up for discussion again before the October meeting 
at the earliest), but I don't see a WG14 document with such a proposal, 
and proposals for the next C standard revision can't now be taken until 
the C2x ballots (DIS, possibly FDIS) have completed, some time in 2024.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH v2 0/4] c2y proposal add monotonicwait support for mtx and ctx

[罗勇刚(Yonggang Luo)]

[-- Attachment #1: Type: text/plain, Size: 1373 bytes --]

On Wed, Jun 21, 2023 at 4:45 AM Joseph Myers <joseph@codesourcery.com>
wrote:
>
> I think it's a misrepresentation to refer to this as a C2y proposal.
> You're proposing a new GNU interface and should describe it as such and
> justify it as such.  Maybe you intend to propose it for C2y or C3x
> (whatever the next C standard revision is - we haven't decided on a
> schedule and that's not up for discussion again before the October meeting
> at the earliest), but I don't see a WG14 document with such a proposal,

This is a prepare for such a proposal, I asked  Jens Gustedt before about
such a  proposal, He suggest me
try do the implementation in libc first, And that's make sense, and it's
make me found the properly function prototype
for this. It's doesn't need to be merged as soon as possible, but give us
an indication that the correct direction to achieve
monotonic mtx/cnd lock/wait support in C2y or C3x, And if that's direction
is correct, I would like to use it in project mesa first and waiting
the C2y or C3x to be appeared with such a proposal.


> and proposals for the next C standard revision can't now be taken until
> the C2x ballots (DIS, possibly FDIS) have completed, some time in 2024.
>
> --
> Joseph S. Myers
> joseph@codesourcery.com



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

Re: [PATCH v2 0/4] c2y proposal add monotonicwait support for mtx and ctx

[Xi Ruoyao]

On Wed, 2023-06-21 at 14:52 +0800, 罗勇刚(Yonggang Luo) via Libc-alpha
wrote:
> It's doesn't need to be merged as soon as possible, but give us
> an indication that the correct direction to achieve
> monotonic mtx/cnd lock/wait support in C2y or C3x, And if that's direction
> is correct, I would like to use it in project mesa first and waiting
> the C2y or C3x to be appeared with such a proposal.

Then you should use [PATCH RFC] in the subject.  Without "RFC" it's
assumed the author consider the patch ready for git master.

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