On Thu, Jun 22, 2023 at 3:05 AM enh wrote: > > > > On Wed, Jun 21, 2023 at 11:39 AM 罗勇刚(Yonggang Luo) wrote: >> >> >> >> On Wed, Jun 21, 2023 at 10:31 PM enh 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 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 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