Re: PSA: Clock drift and pkgin

[Johnny Billquist <bqt%softjar.se@localhost>]

On 2023-12-25 02:17, Robert Elz wrote:
>      Date:        Sun, 24 Dec 2023 13:49:53 +0100
>      From:        Johnny Billquist <bqt%softjar.se@localhost>
>      Message-ID:  <b346af26-88a1-45fe-bb4f-32fb642d66a5%softjar.se@localhost>
>
>    | 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: bqt%softjar.se@localhost             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol