* [PATCH v2 0/4] c2y proposal add monotonicwait support for mtx and ctx @ 2023-06-20 17:17 Yonggang Luo 2023-06-20 17:17 ` [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab Yonggang Luo ` (4 more replies) 0 siblings, 5 replies; 48+ messages in thread From: Yonggang Luo @ 2023-06-20 17:17 UTC (permalink / raw) To: Jens Gustedt, libc-alpha; +Cc: Florian Weimer, 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab 2023-06-20 17:17 [PATCH v2 0/4] c2y proposal add monotonicwait support for mtx and ctx Yonggang Luo @ 2023-06-20 17:17 ` Yonggang Luo 2023-06-20 17:45 ` Zack Weinberg 2023-06-20 17:17 ` [PATCH v2 2/4] time: Implement c23 timespec_get base Yonggang Luo ` (3 subsequent siblings) 4 siblings, 1 reply; 48+ messages in thread From: Yonggang Luo @ 2023-06-20 17:17 UTC (permalink / raw) To: Jens Gustedt, libc-alpha; +Cc: Florian Weimer, 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab 2023-06-20 17:17 ` [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab Yonggang Luo @ 2023-06-20 17:45 ` Zack Weinberg 2023-06-21 6:31 ` 罗勇刚(Yonggang Luo) ` (2 more replies) 0 siblings, 3 replies; 48+ messages in thread From: Zack Weinberg @ 2023-06-20 17:45 UTC (permalink / raw) To: Yonggang Luo, Jens Gustedt, GNU libc development; +Cc: Florian Weimer 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab 2023-06-20 17:45 ` Zack Weinberg @ 2023-06-21 6:31 ` 罗勇刚(Yonggang Luo) 2023-06-21 6:47 ` Xi Ruoyao 2023-06-21 14:26 ` Zack Weinberg 2023-06-21 7:17 ` Xi Ruoyao 2023-06-21 16:19 ` Carlos O'Donell 2 siblings, 2 replies; 48+ messages in thread From: 罗勇刚(Yonggang Luo) @ 2023-06-21 6:31 UTC (permalink / raw) To: Zack Weinberg; +Cc: Jens Gustedt, GNU libc development, Florian Weimer [-- 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab 2023-06-21 6:31 ` 罗勇刚(Yonggang Luo) @ 2023-06-21 6:47 ` Xi Ruoyao 2023-06-21 6:55 ` 罗勇刚(Yonggang Luo) 2023-06-21 14:26 ` Zack Weinberg 1 sibling, 1 reply; 48+ messages in thread From: Xi Ruoyao @ 2023-06-21 6:47 UTC (permalink / raw) To: luoyonggang, Zack Weinberg Cc: Jens Gustedt, GNU libc development, Florian Weimer 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab 2023-06-21 6:47 ` Xi Ruoyao @ 2023-06-21 6:55 ` 罗勇刚(Yonggang Luo) 2023-06-21 7:13 ` Xi Ruoyao 0 siblings, 1 reply; 48+ messages in thread From: 罗勇刚(Yonggang Luo) @ 2023-06-21 6:55 UTC (permalink / raw) To: Xi Ruoyao Cc: Zack Weinberg, Jens Gustedt, GNU libc development, Florian Weimer [-- 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab 2023-06-21 6:55 ` 罗勇刚(Yonggang Luo) @ 2023-06-21 7:13 ` Xi Ruoyao 2023-06-21 7:36 ` 罗勇刚(Yonggang Luo) 0 siblings, 1 reply; 48+ messages in thread From: Xi Ruoyao @ 2023-06-21 7:13 UTC (permalink / raw) To: luoyonggang Cc: Zack Weinberg, Jens Gustedt, GNU libc development, Florian Weimer 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab 2023-06-21 7:13 ` Xi Ruoyao @ 2023-06-21 7:36 ` 罗勇刚(Yonggang Luo) 0 siblings, 0 replies; 48+ messages in thread From: 罗勇刚(Yonggang Luo) @ 2023-06-21 7:36 UTC (permalink / raw) To: Xi Ruoyao Cc: Zack Weinberg, Jens Gustedt, GNU libc development, Florian Weimer [-- 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab 2023-06-21 6:31 ` 罗勇刚(Yonggang Luo) 2023-06-21 6:47 ` Xi Ruoyao @ 2023-06-21 14:26 ` Zack Weinberg 1 sibling, 0 replies; 48+ messages in thread From: Zack Weinberg @ 2023-06-21 14:26 UTC (permalink / raw) To: Yonggang Luo; +Cc: GNU libc development 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab 2023-06-20 17:45 ` Zack Weinberg 2023-06-21 6:31 ` 罗勇刚(Yonggang Luo) @ 2023-06-21 7:17 ` Xi Ruoyao 2023-06-21 16:19 ` Carlos O'Donell 2 siblings, 0 replies; 48+ messages in thread From: Xi Ruoyao @ 2023-06-21 7:17 UTC (permalink / raw) To: Zack Weinberg, Yonggang Luo, Jens Gustedt, GNU libc development Cc: Florian Weimer 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab 2023-06-20 17:45 ` Zack Weinberg 2023-06-21 6:31 ` 罗勇刚(Yonggang Luo) 2023-06-21 7:17 ` Xi Ruoyao @ 2023-06-21 16:19 ` Carlos O'Donell 2023-06-21 17:35 ` Joseph Myers 2 siblings, 1 reply; 48+ messages in thread From: Carlos O'Donell @ 2023-06-21 16:19 UTC (permalink / raw) To: Zack Weinberg, Yonggang Luo, Jens Gustedt, GNU libc development Cc: Florian Weimer 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab 2023-06-21 16:19 ` Carlos O'Donell @ 2023-06-21 17:35 ` Joseph Myers 2023-06-21 17:41 ` 罗勇刚(Yonggang Luo) 2023-06-21 21:26 ` Paul Eggert 0 siblings, 2 replies; 48+ messages in thread From: Joseph Myers @ 2023-06-21 17:35 UTC (permalink / raw) To: Carlos O'Donell Cc: Zack Weinberg, Yonggang Luo, GNU libc development, Florian Weimer 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab 2023-06-21 17:35 ` Joseph Myers @ 2023-06-21 17:41 ` 罗勇刚(Yonggang Luo) 2023-06-21 17:49 ` Andrew Pinski 2023-06-21 19:36 ` Zack Weinberg 2023-06-21 21:26 ` Paul Eggert 1 sibling, 2 replies; 48+ messages in thread From: 罗勇刚(Yonggang Luo) @ 2023-06-21 17:41 UTC (permalink / raw) To: Joseph Myers Cc: Carlos O'Donell, Zack Weinberg, GNU libc development, Florian Weimer [-- 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab 2023-06-21 17:41 ` 罗勇刚(Yonggang Luo) @ 2023-06-21 17:49 ` Andrew Pinski 2023-06-21 17:59 ` 罗勇刚(Yonggang Luo) 2023-06-21 19:36 ` Zack Weinberg 1 sibling, 1 reply; 48+ messages in thread From: Andrew Pinski @ 2023-06-21 17:49 UTC (permalink / raw) To: luoyonggang Cc: Joseph Myers, Carlos O'Donell, Zack Weinberg, GNU libc development, Florian Weimer 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab 2023-06-21 17:49 ` Andrew Pinski @ 2023-06-21 17:59 ` 罗勇刚(Yonggang Luo) 2023-06-21 18:31 ` Arsen Arsenović 0 siblings, 1 reply; 48+ messages in thread From: 罗勇刚(Yonggang Luo) @ 2023-06-21 17:59 UTC (permalink / raw) To: Andrew Pinski Cc: Joseph Myers, Carlos O'Donell, Zack Weinberg, GNU libc development, Florian Weimer [-- 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab 2023-06-21 17:59 ` 罗勇刚(Yonggang Luo) @ 2023-06-21 18:31 ` Arsen Arsenović 2023-06-21 18:42 ` 罗勇刚(Yonggang Luo) 0 siblings, 1 reply; 48+ messages in thread From: Arsen Arsenović @ 2023-06-21 18:31 UTC (permalink / raw) To: luoyonggang Cc: Andrew Pinski, Joseph Myers, Carlos O'Donell, Zack Weinberg, Florian Weimer, libc-alpha [-- 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 --] ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab 2023-06-21 18:31 ` Arsen Arsenović @ 2023-06-21 18:42 ` 罗勇刚(Yonggang Luo) 0 siblings, 0 replies; 48+ messages in thread From: 罗勇刚(Yonggang Luo) @ 2023-06-21 18:42 UTC (permalink / raw) To: Arsen Arsenović Cc: Andrew Pinski, Joseph Myers, Carlos O'Donell, Zack Weinberg, Florian Weimer, libc-alpha [-- 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab 2023-06-21 17:41 ` 罗勇刚(Yonggang Luo) 2023-06-21 17:49 ` Andrew Pinski @ 2023-06-21 19:36 ` Zack Weinberg 1 sibling, 0 replies; 48+ messages in thread From: Zack Weinberg @ 2023-06-21 19:36 UTC (permalink / raw) To: Yonggang Luo, Joseph Myers Cc: Carlos O'Donell, GNU libc development, Florian Weimer 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab 2023-06-21 17:35 ` Joseph Myers 2023-06-21 17:41 ` 罗勇刚(Yonggang Luo) @ 2023-06-21 21:26 ` Paul Eggert 2023-06-22 21:43 ` Joseph Myers 1 sibling, 1 reply; 48+ messages in thread From: Paul Eggert @ 2023-06-21 21:26 UTC (permalink / raw) To: Joseph Myers, Carlos O'Donell Cc: Zack Weinberg, Yonggang Luo, GNU libc development, Florian Weimer 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab 2023-06-21 21:26 ` Paul Eggert @ 2023-06-22 21:43 ` Joseph Myers 2023-06-22 21:48 ` Paul Eggert 0 siblings, 1 reply; 48+ messages in thread From: Joseph Myers @ 2023-06-22 21:43 UTC (permalink / raw) To: Paul Eggert Cc: Carlos O'Donell, Zack Weinberg, Yonggang Luo, GNU libc development, Florian Weimer 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab 2023-06-22 21:43 ` Joseph Myers @ 2023-06-22 21:48 ` Paul Eggert 0 siblings, 0 replies; 48+ messages in thread From: Paul Eggert @ 2023-06-22 21:48 UTC (permalink / raw) To: Joseph Myers Cc: Carlos O'Donell, Zack Weinberg, Yonggang Luo, GNU libc development, Florian Weimer 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH v2 2/4] time: Implement c23 timespec_get base 2023-06-20 17:17 [PATCH v2 0/4] c2y proposal add monotonicwait support for mtx and ctx Yonggang Luo 2023-06-20 17:17 ` [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab Yonggang Luo @ 2023-06-20 17:17 ` Yonggang Luo 2023-06-20 20:37 ` Joseph Myers 2023-06-20 17:17 ` [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 ` (2 subsequent siblings) 4 siblings, 1 reply; 48+ messages in thread From: Yonggang Luo @ 2023-06-20 17:17 UTC (permalink / raw) To: Jens Gustedt, libc-alpha; +Cc: Florian Weimer, 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 2/4] time: Implement c23 timespec_get base 2023-06-20 17:17 ` [PATCH v2 2/4] time: Implement c23 timespec_get base Yonggang Luo @ 2023-06-20 20:37 ` Joseph Myers 2023-06-21 6:42 ` 罗勇刚(Yonggang Luo) 0 siblings, 1 reply; 48+ messages in thread From: Joseph Myers @ 2023-06-20 20:37 UTC (permalink / raw) To: Yonggang Luo; +Cc: Jens Gustedt, libc-alpha, Florian Weimer 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 2/4] time: Implement c23 timespec_get base 2023-06-20 20:37 ` Joseph Myers @ 2023-06-21 6:42 ` 罗勇刚(Yonggang Luo) 0 siblings, 0 replies; 48+ messages in thread From: 罗勇刚(Yonggang Luo) @ 2023-06-21 6:42 UTC (permalink / raw) To: Joseph Myers; +Cc: Jens Gustedt, libc-alpha, Florian Weimer [-- 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH v2 3/4] c11: Switch to use pthread_mutex_clocklock and pthread_cond_clockwait to implement cnd and mtx lock and wait 2023-06-20 17:17 [PATCH v2 0/4] c2y proposal add monotonicwait support for mtx and ctx Yonggang Luo 2023-06-20 17:17 ` [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab Yonggang Luo 2023-06-20 17:17 ` [PATCH v2 2/4] time: Implement c23 timespec_get base Yonggang Luo @ 2023-06-20 17:17 ` Yonggang Luo 2023-06-20 17:17 ` [PATCH v2 4/4] c2y: Add function cnd_timedwait_base and mtx_timedlock_base Yonggang Luo 2023-06-20 20:45 ` [PATCH v2 0/4] c2y proposal add monotonicwait support for mtx and ctx Joseph Myers 4 siblings, 0 replies; 48+ messages in thread From: Yonggang Luo @ 2023-06-20 17:17 UTC (permalink / raw) To: Jens Gustedt, libc-alpha; +Cc: Florian Weimer, 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH v2 4/4] c2y: Add function cnd_timedwait_base and mtx_timedlock_base 2023-06-20 17:17 [PATCH v2 0/4] c2y proposal add monotonicwait support for mtx and ctx Yonggang Luo ` (2 preceding siblings ...) 2023-06-20 17:17 ` [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 @ 2023-06-20 17:17 ` Yonggang Luo 2023-06-20 20:41 ` Joseph Myers 2023-06-20 20:50 ` Joseph Myers 2023-06-20 20:45 ` [PATCH v2 0/4] c2y proposal add monotonicwait support for mtx and ctx Joseph Myers 4 siblings, 2 replies; 48+ messages in thread From: Yonggang Luo @ 2023-06-20 17:17 UTC (permalink / raw) To: Jens Gustedt, libc-alpha; +Cc: Florian Weimer, 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 4/4] c2y: Add function cnd_timedwait_base and mtx_timedlock_base 2023-06-20 17:17 ` [PATCH v2 4/4] c2y: Add function cnd_timedwait_base and mtx_timedlock_base Yonggang Luo @ 2023-06-20 20:41 ` Joseph Myers 2023-06-21 9:21 ` 罗勇刚(Yonggang Luo) 2023-06-20 20:50 ` Joseph Myers 1 sibling, 1 reply; 48+ messages in thread From: Joseph Myers @ 2023-06-20 20:41 UTC (permalink / raw) To: Yonggang Luo; +Cc: Jens Gustedt, libc-alpha, Florian Weimer 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 4/4] c2y: Add function cnd_timedwait_base and mtx_timedlock_base 2023-06-20 20:41 ` Joseph Myers @ 2023-06-21 9:21 ` 罗勇刚(Yonggang Luo) 2023-06-21 9:54 ` Xi Ruoyao ` (2 more replies) 0 siblings, 3 replies; 48+ messages in thread From: 罗勇刚(Yonggang Luo) @ 2023-06-21 9:21 UTC (permalink / raw) To: Joseph Myers; +Cc: Jens Gustedt, libc-alpha, Florian Weimer, enh [-- 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 4/4] c2y: Add function cnd_timedwait_base and mtx_timedlock_base 2023-06-21 9:21 ` 罗勇刚(Yonggang Luo) @ 2023-06-21 9:54 ` Xi Ruoyao 2023-06-21 10:16 ` 罗勇刚(Yonggang Luo) 2023-06-21 12:09 ` Joseph Myers 2023-06-21 14:30 ` enh 2 siblings, 1 reply; 48+ messages in thread From: Xi Ruoyao @ 2023-06-21 9:54 UTC (permalink / raw) To: luoyonggang, Joseph Myers; +Cc: Jens Gustedt, libc-alpha, Florian Weimer, enh 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 4/4] c2y: Add function cnd_timedwait_base and mtx_timedlock_base 2023-06-21 9:54 ` Xi Ruoyao @ 2023-06-21 10:16 ` 罗勇刚(Yonggang Luo) 2023-06-21 10:25 ` Xi Ruoyao 2023-06-21 10:40 ` Florian Weimer 0 siblings, 2 replies; 48+ messages in thread From: 罗勇刚(Yonggang Luo) @ 2023-06-21 10:16 UTC (permalink / raw) To: Xi Ruoyao; +Cc: Joseph Myers, Jens Gustedt, GNU libc, Florian Weimer, enh [-- 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 > ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 4/4] c2y: Add function cnd_timedwait_base and mtx_timedlock_base 2023-06-21 10:16 ` 罗勇刚(Yonggang Luo) @ 2023-06-21 10:25 ` Xi Ruoyao 2023-06-21 10:40 ` Florian Weimer 1 sibling, 0 replies; 48+ messages in thread From: Xi Ruoyao @ 2023-06-21 10:25 UTC (permalink / raw) To: luoyonggang; +Cc: Joseph Myers, Jens Gustedt, GNU libc, Florian Weimer, enh 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 4/4] c2y: Add function cnd_timedwait_base and mtx_timedlock_base 2023-06-21 10:16 ` 罗勇刚(Yonggang Luo) 2023-06-21 10:25 ` Xi Ruoyao @ 2023-06-21 10:40 ` Florian Weimer 2023-06-21 13:23 ` Jₑₙₛ Gustedt 1 sibling, 1 reply; 48+ messages in thread From: Florian Weimer @ 2023-06-21 10:40 UTC (permalink / raw) To: 罗勇刚(Yonggang Luo) Cc: Xi Ruoyao, Joseph Myers, Jens Gustedt, GNU libc, enh * 罗勇刚(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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 4/4] c2y: Add function cnd_timedwait_base and mtx_timedlock_base 2023-06-21 10:40 ` Florian Weimer @ 2023-06-21 13:23 ` Jₑₙₛ Gustedt 0 siblings, 0 replies; 48+ messages in thread From: Jₑₙₛ Gustedt @ 2023-06-21 13:23 UTC (permalink / raw) To: Florian Weimer Cc: 罗勇刚(Yonggang Luo), Xi Ruoyao, Joseph Myers, GNU libc, enh [-- 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 --] ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 4/4] c2y: Add function cnd_timedwait_base and mtx_timedlock_base 2023-06-21 9:21 ` 罗勇刚(Yonggang Luo) 2023-06-21 9:54 ` Xi Ruoyao @ 2023-06-21 12:09 ` Joseph Myers 2023-06-21 14:30 ` enh 2 siblings, 0 replies; 48+ messages in thread From: Joseph Myers @ 2023-06-21 12:09 UTC (permalink / raw) To: luoyonggang; +Cc: Jens Gustedt, libc-alpha, Florian Weimer, enh [-- 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 4/4] c2y: Add function cnd_timedwait_base and mtx_timedlock_base 2023-06-21 9:21 ` 罗勇刚(Yonggang Luo) 2023-06-21 9:54 ` Xi Ruoyao 2023-06-21 12:09 ` Joseph Myers @ 2023-06-21 14:30 ` enh 2023-06-21 15:08 ` Joseph Myers 2023-06-21 18:39 ` 罗勇刚(Yonggang Luo) 2 siblings, 2 replies; 48+ messages in thread From: enh @ 2023-06-21 14:30 UTC (permalink / raw) To: luoyonggang; +Cc: Joseph Myers, Jens Gustedt, libc-alpha, Florian Weimer [-- 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 > ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 4/4] c2y: Add function cnd_timedwait_base and mtx_timedlock_base 2023-06-21 14:30 ` enh @ 2023-06-21 15:08 ` Joseph Myers 2023-06-21 18:39 ` 罗勇刚(Yonggang Luo) 1 sibling, 0 replies; 48+ messages in thread From: Joseph Myers @ 2023-06-21 15:08 UTC (permalink / raw) To: enh; +Cc: luoyonggang, Jens Gustedt, libc-alpha, Florian Weimer 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 4/4] c2y: Add function cnd_timedwait_base and mtx_timedlock_base 2023-06-21 14:30 ` enh 2023-06-21 15:08 ` Joseph Myers @ 2023-06-21 18:39 ` 罗勇刚(Yonggang Luo) 2023-06-21 19:04 ` enh 1 sibling, 1 reply; 48+ messages in thread From: 罗勇刚(Yonggang Luo) @ 2023-06-21 18:39 UTC (permalink / raw) To: enh; +Cc: Joseph Myers, Jens Gustedt, libc-alpha, Florian Weimer [-- 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 4/4] c2y: Add function cnd_timedwait_base and mtx_timedlock_base 2023-06-21 18:39 ` 罗勇刚(Yonggang Luo) @ 2023-06-21 19:04 ` enh 2023-06-21 19:07 ` 罗勇刚(Yonggang Luo) 0 siblings, 1 reply; 48+ messages in thread From: enh @ 2023-06-21 19:04 UTC (permalink / raw) To: luoyonggang; +Cc: Joseph Myers, Jens Gustedt, libc-alpha, Florian Weimer [-- 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 > ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 4/4] c2y: Add function cnd_timedwait_base and mtx_timedlock_base 2023-06-21 19:04 ` enh @ 2023-06-21 19:07 ` 罗勇刚(Yonggang Luo) 2023-06-21 19:18 ` enh 0 siblings, 1 reply; 48+ messages in thread From: 罗勇刚(Yonggang Luo) @ 2023-06-21 19:07 UTC (permalink / raw) To: enh; +Cc: Joseph Myers, Jens Gustedt, libc-alpha, Florian Weimer [-- 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 4/4] c2y: Add function cnd_timedwait_base and mtx_timedlock_base 2023-06-21 19:07 ` 罗勇刚(Yonggang Luo) @ 2023-06-21 19:18 ` enh 2023-06-21 19:38 ` 罗勇刚(Yonggang Luo) 2023-06-21 19:43 ` 罗勇刚(Yonggang Luo) 0 siblings, 2 replies; 48+ messages in thread From: enh @ 2023-06-21 19:18 UTC (permalink / raw) To: luoyonggang; +Cc: Joseph Myers, Jens Gustedt, libc-alpha, Florian Weimer [-- 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 > ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 4/4] c2y: Add function cnd_timedwait_base and mtx_timedlock_base 2023-06-21 19:18 ` enh @ 2023-06-21 19:38 ` 罗勇刚(Yonggang Luo) 2023-06-21 19:41 ` enh 2023-06-21 19:43 ` 罗勇刚(Yonggang Luo) 1 sibling, 1 reply; 48+ messages in thread From: 罗勇刚(Yonggang Luo) @ 2023-06-21 19:38 UTC (permalink / raw) To: enh; +Cc: Joseph Myers, Jens Gustedt, libc-alpha, Florian Weimer [-- 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 4/4] c2y: Add function cnd_timedwait_base and mtx_timedlock_base 2023-06-21 19:38 ` 罗勇刚(Yonggang Luo) @ 2023-06-21 19:41 ` enh 2023-06-21 20:14 ` 罗勇刚(Yonggang Luo) 0 siblings, 1 reply; 48+ messages in thread From: enh @ 2023-06-21 19:41 UTC (permalink / raw) To: luoyonggang; +Cc: Joseph Myers, Jens Gustedt, libc-alpha, Florian Weimer [-- 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 > ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 4/4] c2y: Add function cnd_timedwait_base and mtx_timedlock_base 2023-06-21 19:41 ` enh @ 2023-06-21 20:14 ` 罗勇刚(Yonggang Luo) 0 siblings, 0 replies; 48+ messages in thread From: 罗勇刚(Yonggang Luo) @ 2023-06-21 20:14 UTC (permalink / raw) To: enh; +Cc: Joseph Myers, Jens Gustedt, libc-alpha, Florian Weimer [-- 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 4/4] c2y: Add function cnd_timedwait_base and mtx_timedlock_base 2023-06-21 19:18 ` enh 2023-06-21 19:38 ` 罗勇刚(Yonggang Luo) @ 2023-06-21 19:43 ` 罗勇刚(Yonggang Luo) 1 sibling, 0 replies; 48+ messages in thread From: 罗勇刚(Yonggang Luo) @ 2023-06-21 19:43 UTC (permalink / raw) To: enh; +Cc: Joseph Myers, Jens Gustedt, libc-alpha, Florian Weimer [-- 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 4/4] c2y: Add function cnd_timedwait_base and mtx_timedlock_base 2023-06-20 17:17 ` [PATCH v2 4/4] c2y: Add function cnd_timedwait_base and mtx_timedlock_base Yonggang Luo 2023-06-20 20:41 ` Joseph Myers @ 2023-06-20 20:50 ` Joseph Myers 1 sibling, 0 replies; 48+ messages in thread From: Joseph Myers @ 2023-06-20 20:50 UTC (permalink / raw) To: Yonggang Luo; +Cc: Jens Gustedt, libc-alpha, Florian Weimer 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 0/4] c2y proposal add monotonicwait support for mtx and ctx 2023-06-20 17:17 [PATCH v2 0/4] c2y proposal add monotonicwait support for mtx and ctx Yonggang Luo ` (3 preceding siblings ...) 2023-06-20 17:17 ` [PATCH v2 4/4] c2y: Add function cnd_timedwait_base and mtx_timedlock_base Yonggang Luo @ 2023-06-20 20:45 ` Joseph Myers 2023-06-21 6:52 ` 罗勇刚(Yonggang Luo) 4 siblings, 1 reply; 48+ messages in thread From: Joseph Myers @ 2023-06-20 20:45 UTC (permalink / raw) To: Yonggang Luo; +Cc: Jens Gustedt, libc-alpha, Florian Weimer 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 0/4] c2y proposal add monotonicwait support for mtx and ctx 2023-06-20 20:45 ` [PATCH v2 0/4] c2y proposal add monotonicwait support for mtx and ctx Joseph Myers @ 2023-06-21 6:52 ` 罗勇刚(Yonggang Luo) 2023-06-21 7:14 ` Xi Ruoyao 0 siblings, 1 reply; 48+ messages in thread From: 罗勇刚(Yonggang Luo) @ 2023-06-21 6:52 UTC (permalink / raw) To: Joseph Myers; +Cc: Jens Gustedt, libc-alpha, Florian Weimer [-- 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v2 0/4] c2y proposal add monotonicwait support for mtx and ctx 2023-06-21 6:52 ` 罗勇刚(Yonggang Luo) @ 2023-06-21 7:14 ` Xi Ruoyao 0 siblings, 0 replies; 48+ messages in thread From: Xi Ruoyao @ 2023-06-21 7:14 UTC (permalink / raw) To: luoyonggang, Joseph Myers; +Cc: Jens Gustedt, libc-alpha, Florian Weimer 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
end of thread, other threads:[~2023-06-22 21:48 UTC | newest] Thread overview: 48+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-06-20 17:17 [PATCH v2 0/4] c2y proposal add monotonicwait support for mtx and ctx Yonggang Luo 2023-06-20 17:17 ` [PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab Yonggang Luo 2023-06-20 17:45 ` Zack Weinberg 2023-06-21 6:31 ` 罗勇刚(Yonggang Luo) 2023-06-21 6:47 ` Xi Ruoyao 2023-06-21 6:55 ` 罗勇刚(Yonggang Luo) 2023-06-21 7:13 ` Xi Ruoyao 2023-06-21 7:36 ` 罗勇刚(Yonggang Luo) 2023-06-21 14:26 ` Zack Weinberg 2023-06-21 7:17 ` Xi Ruoyao 2023-06-21 16:19 ` Carlos O'Donell 2023-06-21 17:35 ` Joseph Myers 2023-06-21 17:41 ` 罗勇刚(Yonggang Luo) 2023-06-21 17:49 ` Andrew Pinski 2023-06-21 17:59 ` 罗勇刚(Yonggang Luo) 2023-06-21 18:31 ` Arsen Arsenović 2023-06-21 18:42 ` 罗勇刚(Yonggang Luo) 2023-06-21 19:36 ` Zack Weinberg 2023-06-21 21:26 ` Paul Eggert 2023-06-22 21:43 ` Joseph Myers 2023-06-22 21:48 ` Paul Eggert 2023-06-20 17:17 ` [PATCH v2 2/4] time: Implement c23 timespec_get base Yonggang Luo 2023-06-20 20:37 ` Joseph Myers 2023-06-21 6:42 ` 罗勇刚(Yonggang Luo) 2023-06-20 17:17 ` [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 2023-06-20 17:17 ` [PATCH v2 4/4] c2y: Add function cnd_timedwait_base and mtx_timedlock_base Yonggang Luo 2023-06-20 20:41 ` Joseph Myers 2023-06-21 9:21 ` 罗勇刚(Yonggang Luo) 2023-06-21 9:54 ` Xi Ruoyao 2023-06-21 10:16 ` 罗勇刚(Yonggang Luo) 2023-06-21 10:25 ` Xi Ruoyao 2023-06-21 10:40 ` Florian Weimer 2023-06-21 13:23 ` Jₑₙₛ Gustedt 2023-06-21 12:09 ` Joseph Myers 2023-06-21 14:30 ` enh 2023-06-21 15:08 ` Joseph Myers 2023-06-21 18:39 ` 罗勇刚(Yonggang Luo) 2023-06-21 19:04 ` enh 2023-06-21 19:07 ` 罗勇刚(Yonggang Luo) 2023-06-21 19:18 ` enh 2023-06-21 19:38 ` 罗勇刚(Yonggang Luo) 2023-06-21 19:41 ` enh 2023-06-21 20:14 ` 罗勇刚(Yonggang Luo) 2023-06-21 19:43 ` 罗勇刚(Yonggang Luo) 2023-06-20 20:50 ` Joseph Myers 2023-06-20 20:45 ` [PATCH v2 0/4] c2y proposal add monotonicwait support for mtx and ctx Joseph Myers 2023-06-21 6:52 ` 罗勇刚(Yonggang Luo) 2023-06-21 7:14 ` Xi Ruoyao
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).