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,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 3F5D729341 for ; Mon, 7 Oct 2024 10:11:14 +0200 (CEST) Received: (qmail 20055 invoked by uid 550); 7 Oct 2024 08:11:09 -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 20020 invoked from network); 7 Oct 2024 08:11:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1728288660; x=1728893460; darn=lists.openwall.com; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:to:from:subject:message-id:from:to:cc:subject:date :message-id:reply-to; bh=H5w3MrpwjRwpShq5t7/S+jIdMB3stHqUeu/gp19jkDg=; b=eUiwABbUy6wW04X+TcapQBPKQKv6Gx2VmnpqvdzIDPq67upq8G1IRN+QwvNOL9uTOt qtgW/RjQG4LH7gU7ByGEbvl4+B0CUCdeL0j/6p863liw+iEPMgn8N8ZTcaWcea51fsAm gZEKY6NTysj4g9Z+SIJZDGazlh1GSwa4xigI38BRXaozr+U0YkSezm0fEhcyBIORxoKT //xIh+TZFxKSSH15RQyoJK0Ohno/sHABvE7t6QQGV8rAOt8ADWWI+vckHnEpUdOK4AoC NEVwK96RW4/8nOlPLwzZzjNclVblPqiez29E0Z6Y146waK00hElESYafw1VSZI0hQ7av X7QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728288660; x=1728893460; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:to:from:subject:message-id:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=H5w3MrpwjRwpShq5t7/S+jIdMB3stHqUeu/gp19jkDg=; b=hIRtTWb4+OBeaGegFqqPJt+x5eN8wVW8SjjVfRiH+TBplyLAaDLsMZX9qr12FvIHs9 KqOVK8LejEkSUKpBZ7/t1BSwzk/PvgA5BnUzNsvTXjM3TkdGpkPjcG2Y+tV/pX7HrOpb aOqBTjfGMgkUbIOw4ZIPypLfa753KsIO1I4tp1V/+GOmabOJMU/ORTvREIXdlnRrbRoW EuYXvfpo9ZXIz2A8wHMlAGbHkrB9P4l/nn0TqtLXoDRnYHOMYqeHZablwYEcK4xj9BtY UkXdVwnR9vqaeha/5SkOD4zjOj5uAlq/uwJEG3H5eOeRg/I0+tqQlxQuOEU/0XcXKdOh SzJg== X-Gm-Message-State: AOJu0YwYjRLvoiXNZ3f5WiWS1NFNrNLUJGT+dhkLGkTIiJOBOFJTo0m2 FwUvqKkeQiKTLfH81Yo6p8jEU18tDBcFj3+rW8Ydzy+iy3wru9+5s+tpcg== X-Google-Smtp-Source: AGHT+IHSgUJJDXwcHJkb62xV2gvOWfqpUqp386EXDigwqC/1nwxEb2uMx0MPGfO8eeD/eAuuVe7AXA== X-Received: by 2002:a05:6402:3512:b0:5c8:97dd:3b03 with SMTP id 4fb4d7f45d1cf-5c8d2e9ef80mr8305664a12.33.1728288659535; Mon, 07 Oct 2024 01:10:59 -0700 (PDT) Message-ID: <1722be2aca2514feb191f079164bcafb2f0d9604.camel@gmail.com> From: Daniele GMail To: musl@lists.openwall.com Date: Mon, 07 Oct 2024 10:10:57 +0200 In-Reply-To: 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 Sat, 2024-10-05 at 05:18 +0100, zxuiji wrote: > Since he brought up the function it's likely already in musl >=20 > 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. > > > >=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/function= s/pthread_mutex_clocklock.html > >=20 > > Oh, this is great news. > >=20 > > 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 > > >=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. > >=20 I might be wrong but I don't see it in master tree: am I missing something?