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=-3.1 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 32642 invoked from network); 21 Jun 2023 06:26:23 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 21 Jun 2023 06:26:23 -0000 Received: (qmail 11508 invoked by uid 550); 21 Jun 2023 06:26:21 -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 11473 invoked from network); 21 Jun 2023 06:26:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687328769; x=1689920769; h=to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=BjX0R1aZhe4TgD0MzRRNujoW3ayDYQmRbKP3FL5xJTw=; b=G9Y9Pw5iiLlIqGoU77cu1KNe9GnDBQgKcj3ddcpg8bXyT5zDTfUKCZXiiuHFYjEN3g XH9zL3ugzD/QFdLeFFGYZHdIBgEZDLcdV5RQXayXg/+gdsBfy2p/uO2jDJROkTzoV7C1 699OdcnBr9qtfwYQRBYMyK5iENOBcxlqap+KoKytsAv+xk6r22zccF24tZrNx1/gatPy WJcDZXVmC5+ZNKqD2kFbV1eg3+rCjhLvTuF6s3tr01BOxQmbjdI/SBNVxGdPg1zLhcql Oyl5Mf6qlKpUwB1z4mCHTg1jk6gDvSh3ZzJIgn/rrepRQxvIf+JqD+IC7Y10tOQatBTX oW/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687328769; x=1689920769; h=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=BjX0R1aZhe4TgD0MzRRNujoW3ayDYQmRbKP3FL5xJTw=; b=c5GKsUN9s27iEcf9g1vIX8uautJdu98L1uqD5INU7b8FXzCscS3bKhJhvzG1iGu/ij RTGWI68QMZti1+6+h5OzJj8Vh72wO2A9hkJeEUNb0wspayvAnri8OKTFSS1kDvxlZ0zK OX6cjUp0QYNR0uB6jPy0tlo5hfjK7CVfnCgOyXT6U4WsFX0kZkYG+OhMfMrFYUXrP7hZ 6qM/HsQs8dO8cDL2hqbcegEC5D0xWoiFp88CWuNlaCIjt6ARVogk3TtFovnKpYlRZIRh a1Ha7Q6B0n3/LhUPyyPuodetZJu851dzS/EG8qFXcQkclzcuOvxDUw/kacMT9RuI3ZTT SXDA== X-Gm-Message-State: AC+VfDzez2fhyh0bv8Cag+3PB3Vhf7Gzs4WovNiWAignb4eekQ/62moW xAAotHkYH/5dAOregixM4NWvIY2QkoqiQjJWo0cbohZoEZujqeLM X-Google-Smtp-Source: ACHHUZ7p/3N46M+1kbHiqpv9HxSLyQsoAm1JWqqIRzpgDKhCPRvRZ/R+/hL4PCxmPo/5/+aOTujfXGMxIdXgKho9wYs= X-Received: by 2002:a17:907:3e0a:b0:982:9662:a679 with SMTP id hp10-20020a1709073e0a00b009829662a679mr13971136ejc.9.1687328768707; Tue, 20 Jun 2023 23:26:08 -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:25:58 +0800 Message-ID: To: Rich Felker , Musl Content-Type: multipart/alternative; boundary="000000000000e0cf3805fe9dd740" Subject: Re: [musl] [PATCH v3 0/5] Add posix/pthread_mutex_clocklock posix/pthread_cond_clockdwait c2y/mtx_timedlock_base c2y/cnd_timedwait_base --000000000000e0cf3805fe9dd740 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 > 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 > 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: LKML-style patches are generally used, what makes musl should not use that? If email is the only way to submit patches for musl, I think LKML-style patches have general agreement, otherwise it's better to use github/gitlab to do that. Because the LKML-style patches can be sent by using `git git-send-email` to do that. So the following reasons is not a issue for glibc/linux/qemu and so on, they have much larger volume. > > - 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 --000000000000e0cf3805fe9dd740 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
> adding an extra cost to the existing functions most callers actu= ally
> want to use for the sake of a fringe need, in terms of an extr= a call
> frame layer. That can probably be mitigated by lifting the i= nitial
> trylock, but doing this in a way that's not a mess and d= oesn't
> gratuitously repeat trylocks isn't entirely trivial.=
>
> > I think mtx_timedlock_base cnd_timedwait_base is reas= onable because it's newly added
> > function and won't aff= ect existing c11 threads functions.
> > And it's can be implem= entd with glibc/qnx libc/android bionic without burden.
> > For OS= X it's can be implemented with pthread_cond_timedwait_relative_np
&= gt; > For Windows it's can be implemented with SleepConditionVariabl= eCS
> > For platform have none of these, it's still can fallba= ck to using mtx_timedlock and cnd_timedwait
> > over TIME_UTC
&= gt; >
> > Yonggang Luo (5):
> > =C2=A0 trim spaces of = pthread_cond_timedwait.c and pthread_mutex_timedlock.c
> > =C2=A0 = Rename files for implement pthread_mutex_clocklock and
> > =C2=A0 = =C2=A0 pthread_cond_clockwait
> > =C2=A0 add pthread_mutex_clocklo= ck and pthread_cond_clockdwait
> > =C2=A0 c23: Implement newly bas= e for timespec_get
> > =C2=A0 c2y: Add monotonic timedlock/timedwa= it support for threads mtx/cnd
>
> As a general principle, plea= se groups of associated patches to this
> list as a single mail with = the individual patches as MIME attachments,
> not LKML-style as a gia= nt thread with one message per patch. This is
> to:

LKML-style patches are generally used, what makes musl should not use tha= t?
If email is the only way to submit patches for musl, I think L= KML-style patches have general agreement,
otherwise it's bett= er to use github/gitlab to do that.
Because the LKML-style patches can= be sent by using `git git-send-email` to do that.
So the following rea= sons is not a issue for glibc/linux/qemu and so on, they have much larger v= olume.

>
> - avoid flooding the inboxes of list s= ubscribers
>
> - facilitate discussion/replies that involve mor= e than one patch in
> =C2=A0 the series
>
> - allow revis= ions to be easily introduced in the existing thread for a
> =C2=A0 to= pic 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 sincerely,
Yonggang Luo
--000000000000e0cf3805fe9dd740--