On 2023-12-25 02:17, Robert Elz wrote:
Date: Sun, 24 Dec 2023 13:49:53 +0100
From: Johnny Billquist <b...@softjar.se>
Message-ID: <b346af26-88a1-45fe-bb4f-32fb642d6...@softjar.se>
| In my opinion, all of these POSIX calls that take a time argument should
| really have been done the same as clock_gettime(), in that you specify
| what clock it should be based on.
The next version of POSIX will contain pthread_cond_clockwait() which is
just like pthread_cond_timedwait() but has a clock_id parameter.
| As it is now, it is (or should be according to POSIX) unconditionally
| CLOCK_REALTIME.
Not sure about the current released standard, and too lazy to look ...
but in the coming one that's not true either:
The pthread_cond_timedwait() function shall be equivalent to
pthread_cond_clockwait(), except that it lacks the clock_id argument.
The clock to measure abstime against shall instead come from the
condition variable's clock attribute which can be set by
pthread_condattr_setclock() prior to the condition variable's
creation. If no clock attribute has been set, the default shall be
CLOCK_REALTIME.
Happy to see that this is finally getting fixed. Working on embedded
systems where sometimes you have no clue what the absolute time is,
current POSIX was just close to unusable, and we've had to do some
pretty horrible workarounds.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
