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,HTML_MESSAGE,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 659BF21465 for ; Sat, 5 Oct 2024 06:10:15 +0200 (CEST) Received: (qmail 19824 invoked by uid 550); 5 Oct 2024 04:10: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 19791 invoked from network); 5 Oct 2024 04:10:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1728101399; x=1728706199; darn=lists.openwall.com; h=to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ZPsle5Hd9UKELLDSkNT3IZzPWkeLhP+LtrpVRqG+RCg=; b=FlRutlapsiQQ0A3ukVgdZw2jMKTYOzmP1HdK1KpooPPM8PfltpJTBZK2gOpALrHSeH XbBk6lY1cm/ZGuN+XAxRJZ2I+hCznzlhSfqSVgcP4LQKABCzOwVSPjSSpGkRExVD96pe JanG7YfF4kANPOSIhMkbbjUBkvr8DCoupn8jeRe7wabP7E2JzhorutmwsM1OKJeU7Rmq Ky1GYxq15pZCzZoMo0IoNk2650mIozk1b/lIJZ6JrqwUzQmxo3x9X/QwBG9klITpUpEQ B/wUs+xtfZiYg44biOV6AQ1Nm2mva/ic4P7+G99/wuezpr9yb26NgJL5GxQphb+w0yVR 4hkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728101399; x=1728706199; h=to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ZPsle5Hd9UKELLDSkNT3IZzPWkeLhP+LtrpVRqG+RCg=; b=ruNJ1ta3gXbTmxxKFIhmrcv3MrRYefefBHGw3Wtkz2n6GYWsb9RmdgwYFIkpB6SETg 9Zeg1Cg3xh6iUJjtQmlGN5tjIj6kiKI2hKYqZFbHeDyGbW+uUE89Z7l/K4nr7e7Jcw3q Uf7ezCHHyiWHO1kJP6d8f1zM3pDUY1z6yAJb6Q1QdSzlE7R3fuqtC+w6nB9xqOSSfkxA WBmEBTvApSTzW3Xzj7nyz5vglesVGK5k4OdSGa21cIn5b88It/9eDBvPemQKoMGihx71 eq5RX+AeHgcCus18TrIVMFdWnmQkPqFNszQvJ+fYQ0jQWyQ2bcKdYEupiZ9jk92bq9GB rRxw== X-Gm-Message-State: AOJu0YwXNAxdezS3stV1DVZl1G00lvHhaKx1M0uRs4uRUr0T+ipU/d6w D0zwv1JGbV/i7gxzCVQbel8fnEagW5ila7rFVaRVfqYqg78ZRWi4a1qZE3LZwMcpQ4CBILOQd5l wQ1xeNkJOFSSu/d1YWgVwq/tplf4QmfwV X-Google-Smtp-Source: AGHT+IGPBQXv6B3SR/Nxh0LOps+b7mOd7nUFne5ovvNDN0wZslnb+garneiMuy1mhSDeF9jfrkj2L664vq4Z3zPevWU= X-Received: by 2002:a05:6808:152a:b0:3e0:5b62:4c2a with SMTP id 5614622812f47-3e3c155082dmr3052344b6e.19.1728101399431; Fri, 04 Oct 2024 21:09:59 -0700 (PDT) MIME-Version: 1.0 References: <3e3ac60433f90d4dbf7c421f83f4002b389833da.camel@gmail.com> <0cdb041b-95c7-4040-a4c5-11ff97e696d2@sholland.org> In-Reply-To: From: zxuiji Date: Sat, 5 Oct 2024 05:18:31 +0100 Message-ID: To: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="0000000000000c91ed0623b2f624" Subject: Re: [musl] pthread_mutex_timedlock --0000000000000c91ed0623b2f624 Content-Type: text/plain; charset="UTF-8" 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. > > --0000000000000c91ed0623b2f624 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Since he brought up the function it's likely already i= n musl

On Fri, 4 Oct 2024 at 16:11, Daniele GMail <d.dario76@gmail.com> 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<= br> > > the
> > CLOCK_REALTIME clock; if the Timers option is not supported, the<= br> > > 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=3D1216
> [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.

--0000000000000c91ed0623b2f624--