Yo Hal! On Fri, 13 Jan 2023 13:50:23 -0800 Hal Murray <halmur...@sonic.net> wrote:
> I'm missing the big picture. I've been assuming that gpsd and ntpsec
> and everybody else will use time_t from the system header files.
> (without tweaking anything)
A valid assumption, until now. glibc on 32-bit, now tells us wwe
MUST "tweak" to be 2038 compliant.
> I've been assuming the problem will just go away as distros that
> support 32 bit systems will update their (default) time_t to 64 bits.
Bad assumption. Linus is very insistent on backward ABI compatibility,
so glbic decided the way forward if dual track.
> If 2038 rolls around and a distro is still using 32 bit time_t, gpsd
> is not going to be one of their major problems.
The distros using glibc 2.34 and up, are 2038 compliant, it is
gpsd that is not. Until we "twak".
> [Context was read-only SHM]
> > Sadly, that no longer works on modern CPUs with out of order
> > execution. Unless wrapped in a mutex, or atomic, and that is now a
> > no-no.
>
> I was assuming appropriate memory barriers.
As I said, those are now a no-no.
> What's no-no about atomics?
I causes cache flushes. A 96 core CPU has a huge number of caches to
flush.
> Mutexes seem complicated when shared by 2 programs.
Yes. Locking is a bitch. Thuse the need to go to multi-reader, which
probably means chronyd had it (almost) right.
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin
pgp5gzUopynPe.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
