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_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 8CCB52DE01 for ; Fri, 4 Oct 2024 17:04:58 +0200 (CEST) Received: (qmail 27801 invoked by uid 550); 4 Oct 2024 15:04:52 -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 27769 invoked from network); 4 Oct 2024 15:04:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1728054284; x=1728659084; darn=lists.openwall.com; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:to:reply-to:from:subject:message-id:from:to:cc :subject:date:message-id:reply-to; bh=nnagFaq2acpwO7qdXfFFqqmcaZF6t/WFpNRTq7Nyn4Y=; b=V29UUneuqnYSlrq5RwzXTCW3z6xih/mGMTqhnWYdunMKaWWuglGxqZnq2gS1GiMnRE 5x6yMz78+Ax0YjaiIj3u97ITJd8v39NH4u0bdEoGN95+i1cUaCnH+pi9lA9pnXT9TcSg r3JaHOQzq8PBIXhvwGO7XtZblmKIB8bCuVyxNXH2R7O//ubwr/GCky2zfDXk5ORRbCz/ lL6LRi6NcWndI5MUtgIj7Lz8Gc6d3Si+zw+luPVxLVKr1x6Pbn5wI3ZIBeLyXxlj2Z62 TrWwiRjDbeumrCVo2SCsHqnw/Kyfou+5I17KKBzobSZ/6HEa1nja3tfLOma3KjbINUmS vEig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728054284; x=1728659084; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:to:reply-to:from:subject:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nnagFaq2acpwO7qdXfFFqqmcaZF6t/WFpNRTq7Nyn4Y=; b=XXo4asRJCtYxIF2+BA8QaOSanPWkV0xvm4KbJtdLWwc0Sf/S7E3540qFlCncLLyMRR nuiyib5tX04GhZe5aYWUJBseiD3jw430q3en/iE2L/huz2aMTIKc6K6Uac+HCqIadidD vExglbZ72xl9cdndKwbftRb5KZMC1rRuwI1fWSRDBXuUZVoLfCfue+TTyO9VI509VrXo n2X+d547tm3h57uckhxE/0FRiQpqQe1rWr0jnZHivFBaTn2RRxEpk61hvchhsAE/0UAF 3V3TEP+WcMQLz17ImVAX+m9yXkH8711wtLZ5tVLTZH3o4K254wYwbnW7Yk+0ChpRLxbw +54Q== X-Forwarded-Encrypted: i=1; AJvYcCVC41rmdorfHmuvnsVjxQurOV96HUDz/1fWPb+FaJbeDiXFG0iDY1ops91XuqOgYFs3ssEK@lists.openwall.com X-Gm-Message-State: AOJu0YyX8Xx597h4UiqL3Bdm0fn5XEde3UPYhM2HnPGYzkTdJqxok3oD YLiE0N5Jskn46Lj3fpEFow8+zt1Xul1kB2PRDcks8FcEHmPtZnhKkovFaw== X-Google-Smtp-Source: AGHT+IG9/evoj1RqslNYmowezsmpWT6rF+6ZQxfnov87TCmpIYaaw20bWSNqPCOSehj05tg3xqYoOw== X-Received: by 2002:a05:6402:1d53:b0:5c8:84a8:5170 with SMTP id 4fb4d7f45d1cf-5c8d2eb91c9mr2963173a12.34.1728054283801; Fri, 04 Oct 2024 08:04:43 -0700 (PDT) Message-ID: From: Daniele GMail To: Samuel Holland , musl@lists.openwall.com Date: Fri, 04 Oct 2024 17:04:42 +0200 In-Reply-To: <0cdb041b-95c7-4040-a4c5-11ff97e696d2@sholland.org> References: <3e3ac60433f90d4dbf7c421f83f4002b389833da.camel@gmail.com> <0cdb041b-95c7-4040-a4c5-11ff97e696d2@sholland.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.4-0ubuntu2 MIME-Version: 1.0 Subject: Re: [musl] pthread_mutex_timedlock 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. > >=20 > > From the man page I see > >=20 > > [...] > >=20 > > 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. > >=20 > > [...] > >=20 > > Can anybody explain me why there's no possibility to choose a > > different > > clock like could be done for the pthread_cond_timedwait? >=20 > 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. >=20 > [0]: https://www.austingroupbugs.net/view.php?id=3D1216 > [1]: > https://pubs.opengroup.org/onlinepubs/9799919799.2024edition/functions/pt= hread_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? >=20 > > 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. > >=20 > > Can someone point me to a portable workaround for this? > >=20 > > Thanks in advance, > > Daniele.