tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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:
simonb%NetBSD.org@localhost (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: bqt%softjar.se@localhost             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


Home | Main Index | Thread Index | Old Index