Re: strange message before sending mail

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)