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=-0.9 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, 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 E9FBF2383F for ; Mon, 7 Oct 2024 21:36:10 +0200 (CEST) Received: (qmail 3179 invoked by uid 550); 7 Oct 2024 19:36:04 -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 3129 invoked from network); 7 Oct 2024 19:36:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1728329755; x=1728934555; 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=HAQDPiKt6IcHAVntSlSjqiEmQWfBq0xU1pC5ZnD4BoQ=; b=l3E6Rs8Bfb+lQZ3kXBtES36wCJg29oHOCWN5QfI+N0h26f5C2dyCvJg9yFY+WwrU+g z4A9QJ0xiemJq+JIPYEbnEDyWLnhR/nPp1MAXgdw5/qcT73Zlal5E9E5/Q0/iMiGzJbW 6dWU0YzOQpAymIeSra23cbq4EgCWnfZMBwnI4cG3phxpPTre+Qg1aeHzNfePW7mO/ouv 1HQbP7r86YkqnqIRg/ru4PIAHM7gB925T/AA1BMy3uKZwF8xUAtttG2LX5ZEwRM922hP cf61IAVROQz5Uf1eecjQhu6zafwgYmq0ay3UcJgMuO02k0s3QBQC+OyRagFUUaHIwLEF hYHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728329755; x=1728934555; 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=HAQDPiKt6IcHAVntSlSjqiEmQWfBq0xU1pC5ZnD4BoQ=; b=jDrArMdwxXlrgx0x755TFl+T/5HOD5E0NGwZebBFhgZfzMogTji343Y958xsxLIIxJ SD6cejJqABVQMIPwknVbnHxJn1zuicQ03vBxOTIH/iiPbljFkcFmvJqRzDoxKoDQKhj2 W9sgkgOoqJhWU3cpReMaUmXFx1bpbLT262hSsWl5qqWIU4vXpxADggvTMRR4Ix8sNfG7 gRJBnCu14wROCkYcJS71Z8EhTCBCRtnzCwpzAAYLEIoZtOfE9UKar6a1G1g5BlxEZrjn onW36BqO+jO3nri1NQbktVkICUy43ALI17Z2E2VJCrbsWdlLJiHw3Aqp9ZBC2BkQYsyd d1iA== X-Gm-Message-State: AOJu0Yyy3K+N0UDArm3HXXLZxtH8vV9PQzFvbo1Fho7c7/lZPDAQrGzM OWHPJIRlX9zof8TUuvNRDWLRQc28j4/jNfyYimcYyyVup1ea0twzSkE4IKZlDQAe0tYomreg+Wy SLKgVL4HGWH89BXmhTPlvERsHZx9VfxS1 X-Google-Smtp-Source: AGHT+IEjB7ihZDv3BUMbrXIwaZ5prpM3yWbued9WUaJKAjtoP/xDERV8gfEukLy7CS4Y7hKC40DskHlRePskub0I5g8= X-Received: by 2002:a05:6808:384c:b0:3e2:9954:db67 with SMTP id 5614622812f47-3e3db598166mr338564b6e.2.1728329754434; Mon, 07 Oct 2024 12:35:54 -0700 (PDT) MIME-Version: 1.0 References: <3e3ac60433f90d4dbf7c421f83f4002b389833da.camel@gmail.com> <0cdb041b-95c7-4040-a4c5-11ff97e696d2@sholland.org> <1722be2aca2514feb191f079164bcafb2f0d9604.camel@gmail.com> In-Reply-To: <1722be2aca2514feb191f079164bcafb2f0d9604.camel@gmail.com> From: zxuiji Date: Mon, 7 Oct 2024 20:44:30 +0100 Message-ID: To: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="0000000000001167280623e82143" Subject: Re: [musl] pthread_mutex_timedlock --0000000000001167280623e82143 Content-Type: text/plain; charset="UTF-8" Maybe it's implemented but in a separate branch because it's not yet official 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? > --0000000000001167280623e82143 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Maybe it's implemented but in a separate branch becaus= e it's not yet official

On Mon, 7 Oct 2024 at 09:11, Daniele GMail &= lt;d.dario76@gmail.com> wrote= :
On Sat, 2024-1= 0-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 <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
> > > > the
> > > > CLOCK_REALTIME clock; if the Timers option is not suppo= rted,
> > > > the
> > > > timeout shall be based on the system clock as returned = by the
> > > > time()
> > > > function.
> > > >
> > > > [...]
> > > >
> > > > Can anybody explain me why there's no possibility t= o 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.n= et/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 mu= texes
> > > > 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?
--0000000000001167280623e82143--