[Top][All Lists]

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

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

From: Gary E. Miller
Subject: Re: ✘64-bit time_t on glibc 2.34 and up
Date: Fri, 13 Jan 2023 14:03:06 -0800

Yo Hal!

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

> 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.

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

Attachment: pgpcCuay9vpmM.pgp
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]