Ian Collier via Mutt-dev wrote in <[email protected]>: |On Wed, Aug 19, 2026 at 07:01:59PM +0200, Steffen Nurpmeso wrote: |> Musl impl is | |> #include "syscall.h" |> |> time_t time(time_t *t) |> { |> struct timespec ts; |> __clock_gettime(CLOCK_REALTIME, &ts); |> if (t) *t = ts.tv_sec; |> return ts.tv_sec; |>} | |I believe glibc uses CLOCK_REALTIME_COARSE in that syscall (but |CLOCK_REALTIME for the gettimeofday(2) function). | |If I understand correctly, CLOCK_REALTIME asks the clock hardware |whereas CLOCK_REALTIME_COARSE fetches a stored value that is updated |once per jiffy. | |On modern systems HZ=1000, but my testing showed a delay of up to 1.53ms |on x86_64 and 1.08ms on arm64.
I see, thanks. Also Vincent's 4e40eff0b5737 Linux commit. Never had anything to do with _COARSE until now (at least actively), and am not fluent in speaking jiffies. Actually i am totally surprised that the Linux VFS used to use _COARSE always. Since, actually, i seem to memorize some cacheline-aligned "read-only" location that is synced "from the time interrupt" and simply read from anyone else. Could be this was FreeBSD, then, maybe. But maybe, and likely, i am not thinking the "why" on using _COARSE through. "relatime" and such, yes. Anyway, great this really had a solution beyond "filesystem bug". I have never seen this myself, even though i am on Linux again for over seven years now. The MUA i maintain uses mtime checks, down to nanoseconds if available ... it should likely be changed to mask out for 100th of a second, or, say, a 64th, a 32th or another nice power of two of a second, or so. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
