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_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:
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
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo