Re: ✘64-bit time_t on glibc 2.34 and up

[Gary E. Miller]

Yo Hal!

On Fri, 13 Jan 2023 13:50:23 -0800
Hal Murray <halmurray@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
        gem@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

pgpcCuay9vpmM.pgp
Description: OpenPGP digital signature