Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a5d04339781f760d77d2a49588be776d3efc258c.camel@gmail.com>
Date: Fri, 04 Oct 2024 17:04:42 +0200
From: Daniele GMail <d.dario76@...il.com>
To: Samuel Holland <samuel@...lland.org>, musl@...ts.openwall.com
Subject: Re: 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.
> > 
> > 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.

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.