On Wed, Jun 21, 2023 at 6:47 AM Rich Felker <dalias@libc.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