emacs-devel
[Top][All Lists]
Advanced

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

Re: nanosecond-resolution time stamps


From: Stefan Monnier
Subject: Re: nanosecond-resolution time stamps
Date: Fri, 01 Jul 2011 11:55:45 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

> Emacs currently uses microsecond-resolution time stamps internally,
> whereas GNU and similar operating systems have all gone to
> nanosecond-resolution time stamps internally.  This mismatch leads to
> problems, for example, Emacs mishandles file time stamps when it
> copies them.  I have prepared a set of patches to fix this, and would
> like them to be considered for Emacs 24 if possible or for a later
> version if not.  I'll send them in other email messages shortly.

I think I'd rather wait for Emacs-24.2 for this change, tho maybe
I could be convinced otherwise.

> The basic idea of these patches is to add 3 digits to the time stamp
> format.  For example, currently (current-time) might return
> (19981 28208 421496); with the patches, it returns
> (19981 28208 421496053) at exactly the same instant.  That is, the
> last number of the Emacs internal time stamp now counts nanoseconds,
> not microseconds.  (On older machines that do not support finegrained
> time stamps the trailing digits are always 000.)

> If we're on a 32-bit machine and the nanosecond count exceeds 2**29,
> Emacs falls back on floating point to represent the out-of-range
> integer.

So we'll fallback on a floating point here about half the time?
I don't like that idea very much, it sounds like a source of problems.
We could actually stay within the fixnum limits by using the sign
bit, but that might introduce other problems.

> This change to the internal time stamp format is an incompatible
> change and might cause problems with external packages.  If you like,
> it'd be easy to alter to the patch to use any other reasonable format.
> For example, if you'd prefer the format (19981 28208 421496 053)

That would reduce compatibility problems, most likely.
Tho we might as well add 6 more digits rather than just 3 (just so that
all the sub-second integers encode the same number of digits).
Of course using a decimal encoding sounds like we're back in the bad old
days, but I guess we're stuck with it for now.


        Stefan



reply via email to

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