|
From: | Paul Eggert |
Subject: | Re: Time resolution in Emacs |
Date: | Sat, 23 Apr 2022 17:56:01 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 |
On 4/22/22 23:27, Eli Zaretskii wrote:
There's no reason to expect Emacs to be able to support such applications on all platforms.
Quite right. Many people don't synchronize their clocks at all, and on their systems Emacs can't generate accurate timestamps.
However, that doesn't mean Emacs should be sloppy about timestamps. If an OS has two low-level time primitives A and B, and A's resolution is 100 ms while B's is 1 ms, surely Emacs should prefer B. Using B helps apps that can use 1-ms timestamps in a well-synchronized environment, and it doesn't hurt apps that don't care about timestamp resolution.
Not to mention that synchronizing clocks to millisecond accuracy on non-RT systems is in most cases futile, because the OS doesn't provide reliable timings to that accuracy anyway.
Even if one limits one's attention to NTP on non-realtime systems it's not hard to get agreement on a LAN to better than 10 ms, counting OS jitter. And better-than-10-ms accuracy is growing in popularity, due to applications that need good clocks and get them via PTP or other means. I regularly use networks that are synchronized better than 10 ms, and I wouldn't pooh-pooh the need for this sort of thing in apps that coordinate with others.
We don't _insist_ on providing low-accuracy timestamps, but we should definitely be certainly concerned about adding such non-trivial complexity to Emacs
It sounds like we have miscommunicated, as this comment seems to disagree with your email of a couple of days ago that said "There's no problem whatsoever to provide high-resolution time stamps on MS-Windows".
If the question is whether to use a less-accurate method A or more-accurate method B to obtain timestamps, where Emacs continues its current practice of converting the timestamps to 1-nanosecond resolution internally before the user sees the timestamps, then I don't see why Emacs should prefer A to B.
[Prev in Thread] | Current Thread | [Next in Thread] |