From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 32195 invoked from network); 21 Jun 2023 06:11:19 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 21 Jun 2023 06:11:19 -0000 Received: (qmail 30005 invoked by uid 550); 21 Jun 2023 06:11:13 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 29966 invoked from network); 21 Jun 2023 06:11:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687327861; x=1689919861; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=N0ktH+9WKj6z5cxzH7fIqvdxP2R/y9vRO0QiYGLHcTg=; b=QSIeGP43tFlEjNRJBcrrBX1v/2cQ6C7D+9lEtpG6fpb8i+tQmG4qRxyMsWKqZ+DmwR jqFrLj0C+Ziby0KsRMq3HLjiQTKiwh8MKmGz8jQI3sG1lK9m8Iizwh+fZ9QzHRqkLgih OQXWVT9W4P8G/KbyvbArQoThDqcWfbqG1ZEUBM2uq9swEaoLkdM2Ct9YjMQd+NkK4Uir jFw6jvAUFylPbz/fsxJw5ZwJ2QstEFriBEtBRM8pH63TTipfojh61Yh+7zLbcghUz73M XnU42v2yEVDtqefb2PDoxB6hjvzpMclHj1aktteljXRKGSmFNtOZQK4My7fFLkZYjEB9 LRIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687327861; x=1689919861; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=N0ktH+9WKj6z5cxzH7fIqvdxP2R/y9vRO0QiYGLHcTg=; b=lHLiAeQpTp0reHjADd5o+joA3SVPMkXA9oNkJ7UXDmJKduwQvzYv866NYeUFKmu5F6 /9RCJDhuLC9cdZaQ8tTNSXQZGwHjVjdj0Xfvat+XB4BKWm8PJF72XFlVaAxh0fSfiiB6 ypbzqSnsiJkIGlRU6MxoaYkocZJtKvmLiVwdXrdDM4elMP1RIOOKXZTotoBCG5M9zryX SgT7g93NR5QiiRCeL4ZP1T7F0R1FoZStHFRr5xCDNwMlcmsFpg9iGcCpz/2h0EGukJfl ts/b55D5hqN+Z7BsK/H1DOpMMOUhJw7S6IE2BJz9s20wr8+9kx/c8ovzbp2SEOhW5JCg zMXQ== X-Gm-Message-State: AC+VfDzahEL42Caqom5STAK5Azx/AxxnWFYy64mnWmCYYDtKMvQX2nnI LFhHhazvgcZgZj+7TUq5SFePSiOPzH7uUs0ZSqs= X-Google-Smtp-Source: ACHHUZ4Tuvgk0oiaw+ivzE19JobScjh+XaXGwgiDIBO3McYHUlO71dO8xIf5ARBYZe60lo0AH2Xi9ziTA5d8MEjIQ/k= X-Received: by 2002:a17:907:72c2:b0:974:5ce6:f9f6 with SMTP id du2-20020a17090772c200b009745ce6f9f6mr13543442ejc.10.1687327861370; Tue, 20 Jun 2023 23:11:01 -0700 (PDT) MIME-Version: 1.0 References: <20230620143703.1415-1-luoyonggang@gmail.com> <20230620224704.GI4163@brightrain.aerifal.cx> In-Reply-To: <20230620224704.GI4163@brightrain.aerifal.cx> From: =?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1byk=?= Date: Wed, 21 Jun 2023 14:10:50 +0800 Message-ID: To: Rich Felker Cc: Jens Gustedt , enh , musl@lists.openwall.com Content-Type: multipart/alternative; boundary="000000000000cbf35605fe9da11e" Subject: Re: [musl] [PATCH v3 0/5] Add posix/pthread_mutex_clocklock posix/pthread_cond_clockdwait c2y/mtx_timedlock_base c2y/cnd_timedwait_base --000000000000cbf35605fe9da11e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 21, 2023 at 6:47=E2=80=AFAM Rich Felker wrote= : > > On Tue, Jun 20, 2023 at 10:36:58PM +0800, Yonggang Luo wrote: > > Currently, musl doesn't have pthread_mutex_clocklock pthread_cond_clockdwait, but > > glibc, android bionic, qnx libc already have these two functions, so implement them in > > musl. > > > > And for c11 threads, the mtx and cnd doesn't support for monotonic timedlock and timedwait; > > So add a proposaled 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. > > > > And indeed mtx_timedlock_base and cnd_timedwait_base can be implemented ontop of > > posix/pthread_mutex_clocklock posix/pthread_cond_clockdwait, so I implemented > > posix/pthread_mutex_clocklock posix/pthread_cond_clockdwait first in musl. > > Implementation of any function in this family is contingent on > standardization; musl won't add things in a namespace likely to > conflict with future standardization that's not at least already very > far along the road to being standardized. > > I believe the corresponding pthread functions are already on that > path, but the c11-thread-api ones afaik aren't. Adding support for the > former was raised in the past, and the concern was that it may be Do you means the pthread functions is already on the way? where is it and > adding an extra cost to the existing functions most callers actually > want to use for the sake of a fringe need, in terms of an extra call > frame layer. That can probably be mitigated by lifting the initial > trylock, but doing this in a way that's not a mess and doesn't We can use always_inline to avoid that. > gratuitously repeat trylocks isn't entirely trivial. > > > I think mtx_timedlock_base cnd_timedwait_base is reasonable because it's newly added > > function and won't affect existing c11 threads functions. > > And it's can be implementd with glibc/qnx libc/android bionic without burden. > > For OS X it's can be implemented with pthread_cond_timedwait_relative_n= p > > For Windows it's can be implemented with SleepConditionVariableCS > > For platform have none of these, it's still can fallback to using mtx_timedlock and cnd_timedwait > > over TIME_UTC > > > > Yonggang Luo (5): > > trim spaces of pthread_cond_timedwait.c and pthread_mutex_timedlock.c > > Rename files for implement pthread_mutex_clocklock and > > pthread_cond_clockwait > > add pthread_mutex_clocklock and pthread_cond_clockdwait > > c23: Implement newly base for timespec_get > > c2y: Add monotonic timedlock/timedwait support for threads mtx/cnd > > As a general principle, please groups of associated patches to this > list as a single mail with the individual patches as MIME attachments, > not LKML-style as a giant thread with one message per patch. This is > to: how to do that? > > - avoid flooding the inboxes of list subscribers > > - facilitate discussion/replies that involve more than one patch in > the series > > - allow revisions to be easily introduced in the existing thread for a > topic rather than starting a new one each time there's a revision. > > Rich -- =E6=AD=A4=E8=87=B4 =E7=A4=BC =E7=BD=97=E5=8B=87=E5=88=9A Yours sincerely, Yonggang Luo --000000000000cbf35605fe9da11e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jun 21, 2023 at 6:47=E2=80=AFAM Rich Felke= r <dalias@libc.org> wrote:
= >
> On Tue, Jun 20, 2023 at 10:36:58PM +0800, Yonggang Luo wrote:<= br>> > Currently, musl doesn't have pthread_mutex_clocklock pthre= ad_cond_clockdwait, but
> > glibc, android bionic, qnx libc alread= y have these two functions, so implement them in
> > musl.
>= >
> > And for c11 threads, the mtx and cnd doesn't support= for monotonic timedlock and timedwait;
> > So add a proposaled fu= nction mtx_timedlock_base cnd_timedwait_base to do that.
> > The p= rotype of these two functions is:
> > int mtx_timedlock_base(mtx_t= *restrict m, int time_base, const struct timespec *restrict ts);
> &= gt; int cnd_timedwait_base(cnd_t *restrict c, mtx_t *restrict m, int time_b= ase, const struct timespec *restrict ts);
> > The time_base at lea= st can be TIME_UTC/TIME_MONOTONIC, the implementer can implement it with an= y provided
> > TIME_* base parameter provided in c2y time.h, if TI= ME_MONOTONIC can not natively supported, fallback to TIME_UTC
> > = should provided, for other TIME_* base parameter, it's implementer'= s choice.
> >
> > And indeed mtx_timedlock_base and cnd_t= imedwait_base =C2=A0can be implemented ontop of
> > posix/pthread_= mutex_clocklock posix/pthread_cond_clockdwait, so I implemented
> >= ; posix/pthread_mutex_clocklock posix/pthread_cond_clockdwait first in musl= .
>
> Implementation of any function in this family is continge= nt on
> standardization; musl won't add things in a namespace lik= ely to
> conflict with future standardization that's not at least= already very
> far along the road to being standardized.
>
= > I believe the corresponding pthread functions are already on that
&= gt; path, but the c11-thread-api ones afaik aren't. Adding support for = the
> former was raised in the past, and the concern was that it may = be

Do you means the pthread functions is already on the = way? where is it and=C2=A0


> adding an extr= a cost to the existing functions most callers actually
> want to use = for the sake of a fringe need, in terms of an extra call
> frame laye= r. That can probably be mitigated by lifting the initial
> trylock, b= ut doing this in a way that's not a mess and doesn't

=
We can use always_inline to avoid that.

> gratu= itously repeat trylocks isn't entirely trivial.
>
> > I = think mtx_timedlock_base cnd_timedwait_base is reasonable because it's = newly added
> > function and won't affect existing c11 threads= functions.
> > And it's can be implementd with glibc/qnx libc= /android bionic without burden.
> > For OS X it's can be imple= mented with pthread_cond_timedwait_relative_np
> > For Windows it&= #39;s can be implemented with SleepConditionVariableCS
> > For pla= tform have none of these, it's still can fallback to using mtx_timedloc= k and cnd_timedwait
> > over TIME_UTC
> >
> > Yo= nggang Luo (5):
> > =C2=A0 trim spaces of pthread_cond_timedwait.c= and pthread_mutex_timedlock.c
> > =C2=A0 Rename files for impleme= nt pthread_mutex_clocklock and
> > =C2=A0 =C2=A0 pthread_cond_cloc= kwait
> > =C2=A0 add pthread_mutex_clocklock and pthread_cond_cloc= kdwait
> > =C2=A0 c23: Implement newly base for timespec_get
&g= t; > =C2=A0 c2y: Add monotonic timedlock/timedwait support for threads m= tx/cnd
>
> As a general principle, please groups of associated = patches to this
> list as a single mail with the individual patches a= s MIME attachments,
> not LKML-style as a giant thread with one messa= ge per patch. This is
> to:

how to do that?
<= div>
>
> - avoid flooding the inboxes of list subscribers
&g= t;
> - facilitate discussion/replies that involve more than one patch= in
> =C2=A0 the series
>
> - allow revisions to be easil= y introduced in the existing thread for a
> =C2=A0 topic rather than = starting a new one each time there's a revision.
>
> Rich


--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E6=AD=A4=E8=87=B4=E7=A4=BC
=E7=BD=97=E5=8B=87=E5=88=9A
Yours
=C2=A0 =C2=A0 sincere= ly,
Yonggang Luo
--000000000000cbf35605fe9da11e--