this post was submitted on 26 Aug 2023
3 points (80.0% liked)
General Programming Discussion
7816 readers
2 users here now
A general programming discussion community.
Rules:
- Be civil.
- Please start discussions that spark conversation
Other communities
Systems
Functional Programming
Also related
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I guess the question is: what are you generating where this is a possibility of overlap within the de facto resolution? I can't see filesystem writes needing this level of (nanosecond) accuracy within my lifetime, but happy to be corrected.
Feels borderline YAGNI, but also curious if there are real usecases for this. If there are I expect they are related to low level build activities and not high level I/O operations.
Good point 👍
Likewise, I never thought I'd need any timestamp w/ a finer resolution than millis, until my tests started failing:
There is a feature in bmakelib (called
!!logged
) which logs the stdout/err of a given target to disk. When I was writing tests for it, I noticed that occasionally my tests fail where they shouldn't have (for context, the tests used to create files w/ millis resolution and then check the contents.) Turned out the my tests were fast enough that more than 1 of them would run and finish in a single millisecond causing the "expected" files to be overwritten.That's how I got to thinking that it may be something which can be added to bmakelib.
The benefit is that you don't need to do much and you ensure the timestamp has a high resolution. That will make it harder to produce difficult-to-debug bugs 😅
The downsides are 1) cognitive load (yet another thing to know about) 2) filenames/variables/... will have 3 extra characters which stand for µ fraction.
Does that make sense?