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.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SUBJ_LACKS_WORDS autolearn=no 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 DFF5D2DBB7 for ; Fri, 4 Oct 2024 16:22:15 +0200 (CEST) Received: (qmail 13712 invoked by uid 550); 4 Oct 2024 14:22:10 -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 13671 invoked from network); 4 Oct 2024 14:22:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sholland.org; h= cc:content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1728051397; x=1728137797; bh=UAd13yLBwZ5C8TyUtGg9IztgpZuiRlnY6be1YORADUM=; b= pbK3tdQxGCWy6QVo28qcf6zBm8L92kdR4ZElXjnRJtopwCA2nllrXSvwnOm267eo M+m7SK5FbtpbQFfPUm1CX2nm/7kPabvyutQaxZsKdcnP2N/uenx4suMfDtutHDcH zZ/NoNfZniKCAP7iW242QMcQz4W2lxIgpdn6iY2UCXwpm+2/FK8GbzCu9xWSxztU a3Td+S6O1M/1RJ2k1XAkGdpKempYJ7Mm7j7kRM90FJ/KUifVcvB2ZbgiFBN4j5bx 7eSfRTo6dLn1Uz2BbERalzhM8G4KtSsSKlx+DJ1AqgxRs9xweHBfx9jke3RpbLEy 7fqeLRJ0eeht485YHjyKTQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1728051397; x= 1728137797; bh=UAd13yLBwZ5C8TyUtGg9IztgpZuiRlnY6be1YORADUM=; b=o xAXPw7UBwPF5AKVyHva0M7ijSWyDZRzrNG5NDLfCWJ+gg8k2HLOnvlYRZKjuL4/Z alrC68jMnUqJ32IaZYIQKBPrfkczO5SS5oA4STTT543VaDlCS2dJWmO72WLQUJqV UifIrCE1hbkcEqzw3g1wNwMCPA7/tYKENY2kgKDzQ2d9NqBz16SnRE+MVfQEtAKZ BP6bqQqZ6AuyhTb+0DxYARyWIqa8+YETWUwg9aLTuT8nxBddUc60tAWz0V+zEEGx p2xw2FJs8UI4uCT+5Hi7KfNMw/RHRCSrQc5qqsqPS2sKZ7HoZp4rg2/zuKJa9ALP ithptYkMuRW8882+bFiUg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvddvfedgjeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefkffggfg fuvfhfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpefurghmuhgvlhcujfholhhlrghn ugcuoehsrghmuhgvlhesshhhohhllhgrnhgurdhorhhgqeenucggtffrrghtthgvrhhnpe fgheeigfelteevudffuedugfeileejjedtffegteettdejuddvuedvffeiteevheenucff ohhmrghinheprghushhtihhnghhrohhuphgsuhhgshdrnhgvthdpohhpvghnghhrohhuph drohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm pehsrghmuhgvlhesshhhohhllhgrnhgurdhorhhgpdhnsggprhgtphhtthhopedvpdhmoh guvgepshhmthhpohhuthdprhgtphhtthhopehmuhhslheslhhishhtshdrohhpvghnfigr lhhlrdgtohhmpdhrtghpthhtohepugdruggrrhhiohejieesghhmrghilhdrtghomh X-ME-Proxy: Feedback-ID: i0ad843c9:Fastmail Message-ID: <0cdb041b-95c7-4040-a4c5-11ff97e696d2@sholland.org> Date: Fri, 4 Oct 2024 09:16:35 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: musl@lists.openwall.com, Daniele GMail References: <3e3ac60433f90d4dbf7c421f83f4002b389833da.camel@gmail.com> From: Samuel Holland Content-Language: en-US In-Reply-To: <3e3ac60433f90d4dbf7c421f83f4002b389833da.camel@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [musl] pthread_mutex_timedlock 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 > 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.