Re: PSA: Clock drift and pkgin

On 2023-12-24 11:43, Johnny Billquist wrote:
> On 2023-12-24 09:26, Michael van Elst wrote:
>> [email protected] (Simon Burge) writes:
>>
>>> qemu uses ppoll() which is implemented with pollts() to do emulated
>>> timers, so that doesn't help here.  I don't know what simh uses,nor
>>> any of the other emulators.
>>
>> simh uses pthread_cond_timedwait().
>>
>> This actually waits using TIMER_ABSTIME for a deadline, but which is
>> converted to a timeout with ts2timo() and passed to sleepq_block()
>> as a number of ticks to wait for.
> 
> Oh? So we are actually not POSIX compliant on that one? Interesting.
> (POSIX explicitly says that the timeout should be for an absolute time, 
> which means that if you for example update the clock, moving it 
> backwards, the timeout should still only happen when that time arrives, 
> and not after some precomputed number of ticks.)

By the way - I should point out that I am not advocating that we change 
this to be POSIX compliant. I do think POSIX is broken here.

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.
As it is now, it is (or should be according to POSIX) unconditionally 
CLOCK_REALTIME. But depending on what you are doing, CLOCK_MONOTONIC 
might be what you really wished you could use.
I think Linux have some private extension to the whole thing, which 
makes it possible to pick other clocks, but I've forgotten the details.

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: [email protected]             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol