[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAE2XoE_wy2dsgcBrQTVgirzcwsW5R1sFj1MoZBbDDDuKMMUReA@mail.gmail.com>
Date: Wed, 21 Jun 2023 14:25:58 +0800
From: 罗勇刚(Yonggang Luo) <luoyonggang@...il.com>
To: Rich Felker <dalias@...c.org>, Musl <musl@...ts.openwall.com>
Subject: Re: [PATCH v3 0/5] Add posix/pthread_mutex_clocklock
posix/pthread_cond_clockdwait c2y/mtx_timedlock_base c2y/cnd_timedwait_base
On Wed, Jun 21, 2023 at 6:47 AM Rich Felker <dalias@...c.org> 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_np
> > 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
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
