From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SUBJ_LACKS_WORDS autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id C3FC42343F for ; Wed, 9 Oct 2024 22:34:04 +0200 (CEST) Received: (qmail 31846 invoked by uid 550); 9 Oct 2024 20:33:57 -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 x-ms-reactions: disallow Received: (qmail 31803 invoked from network); 9 Oct 2024 20:33:57 -0000 Date: Wed, 9 Oct 2024 16:33:48 -0400 From: Rich Felker To: zxuiji Cc: musl@lists.openwall.com Message-ID: <20241009203346.GK10433@brightrain.aerifal.cx> References: <3e3ac60433f90d4dbf7c421f83f4002b389833da.camel@gmail.com> <0cdb041b-95c7-4040-a4c5-11ff97e696d2@sholland.org> <1722be2aca2514feb191f079164bcafb2f0d9604.camel@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] pthread_mutex_timedlock On Mon, Oct 07, 2024 at 08:44:30PM +0100, zxuiji wrote: > Maybe it's implemented but in a separate branch because it's not yet > official Could you stick to providing information you can verify when trying to help folks on the list rather than just speculating? The clocklock functions, along with various other functionality in the recently published POSIX and C revisions, are not yet implemented. They should be added sometime soon though. FWIW, the kinds of errors that can be hit from clock changing are non-issues if you have NTP configured to only make skew adjustments rather than jumping the clock. > On Mon, 7 Oct 2024 at 09:11, Daniele GMail wrote: > > > On Sat, 2024-10-05 at 05:18 +0100, zxuiji wrote: > > > Since he brought up the function it's likely already in musl > > > > > > On Fri, 4 Oct 2024 at 16:11, Daniele GMail > > > wrote: > > > > On Fri, 2024-10-04 at 09:16 -0500, Samuel Holland wrote: > > > > > On 10/4/24 08:02, Daniele GMail wrote: > > > > > > Hi, > > > > > > I have a question about pthread_mutex_timedlock. > > > > > > > > > > > > From the man page I see > > > > > > > > > > > > [...] > > > > > > > > > > > > If the Timers option is supported, the timeout shall be based > > > > > > on > > > > > > the > > > > > > CLOCK_REALTIME clock; if the Timers option is not supported, > > > > > > the > > > > > > timeout shall be based on the system clock as returned by the > > > > > > time() > > > > > > function. > > > > > > > > > > > > [...] > > > > > > > > > > > > Can anybody explain me why there's no possibility to choose a > > > > > > different > > > > > > clock like could be done for the pthread_cond_timedwait? > > > > > > > > > > This is an omission in the standard[0], that was resolved in > > > > > POSIX > > > > > 2024[1] by adding pthread_mutex_clocklock(), which does what you > > > > > want. > > > > > > > > > > [0]: https://www.austingroupbugs.net/view.php?id=1216 > > > > > [1]: > > > > > > > https://pubs.opengroup.org/onlinepubs/9799919799.2024edition/functions/pthread_mutex_clocklock.html > > > > > > > > Oh, this is great news. > > > > > > > > But guess that since this is dated 2024 is not yet part of musl > > > > 1.2.5 > > > > right? Are there plans on when it will be available? > > > > > > > > > > > > > > > I have a lot of places in my code where timedlock of mutexes > > > > > > affected > > > > > > by time changes could lead to problems and it is really > > > > > > difficult > > > > > > to > > > > > > distinguish timeouts caused by time changes from other ones in > > > > > > order to > > > > > > decide how to react. > > > > > > > > > > > > Can someone point me to a portable workaround for this? > > > > > > > > > > > > Thanks in advance, > > > > > > Daniele. > > > > > > > > I might be wrong but I don't see it in master tree: am I missing > > something? > >