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=-1.7 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_LOW,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 18441 invoked from network); 20 Jun 2023 22:47:23 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 20 Jun 2023 22:47:23 -0000 Received: (qmail 12253 invoked by uid 550); 20 Jun 2023 22:47:19 -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 12218 invoked from network); 20 Jun 2023 22:47:18 -0000 Date: Tue, 20 Jun 2023 18:47:04 -0400 From: Rich Felker To: Yonggang Luo Cc: Jens Gustedt , enh , musl@lists.openwall.com Message-ID: <20230620224704.GI4163@brightrain.aerifal.cx> References: <20230620143703.1415-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230620143703.1415-1-luoyonggang@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [PATCH v3 0/5] Add posix/pthread_mutex_clocklock posix/pthread_cond_clockdwait c2y/mtx_timedlock_base c2y/cnd_timedwait_base 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: - 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