From: Daniele GMail <d.dario76@gmail.com>
To: musl@lists.openwall.com
Subject: Re: [musl] pthread_mutex_timedlock
Date: Mon, 07 Oct 2024 10:10:57 +0200 [thread overview]
Message-ID: <1722be2aca2514feb191f079164bcafb2f0d9604.camel@gmail.com> (raw)
In-Reply-To: <CAOZ3c1qsnRpen7qffb-QT4Vja0qoHwcoa2v26HKdZOTsmnSmMw@mail.gmail.com>
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 <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 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?
next prev parent reply other threads:[~2024-10-07 8:11 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-04 13:02 Daniele GMail
2024-10-04 14:16 ` Samuel Holland
2024-10-04 15:04 ` Daniele GMail
2024-10-05 4:18 ` zxuiji
2024-10-07 8:10 ` Daniele GMail [this message]
2024-10-07 19:44 ` zxuiji
2024-10-09 20:33 ` Rich Felker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1722be2aca2514feb191f079164bcafb2f0d9604.camel@gmail.com \
--to=d.dario76@gmail.com \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).