Attempt to fix the sporadic uvar test failures on Linux

We identify when the universal variable file has changed out from under us by
comparing a bunch of fields from its stat: inode, device, size, high-precision
timestamp, generation. Linux aggressively reuses inodes, and the size may be
the same by coincidence (which is the case in the tests). Also, Linux
officially has nanosecond precision, but in practice it seems to only uses
millisecond precision for storing mtimes. Thus if there are three or more
updates within a millisecond, every field we check may be the same, and we are
vulnerable to the ABA problem. I believe this explains the occasional test
failures.

The solution is to manually set the nanosecond field of the mtime timestamp to
something unlikely to be duplicated, like a random number, or better yet, the
current time (with nanosecond precision). This is more in the spirit of the
timestamp, and it means we're around a million times less likely to collide.
This seems to fix the tests.

1 files changed, 5 insertions, 0 deletions

diff --git a/src/wutil.h b/src/wutil.h
index 5c9a0ec2..9897439a 100644
--- a/src/wutil.h
+++ b/src/wutil.h
@@ -143,6 +143,8 @@ struct file_id_t
     uint64_t size;
     time_t change_seconds;
     long change_nanoseconds;
+    time_t mod_seconds;
+    long mod_nanoseconds;
     uint32_t generation;
     
     bool operator==(const file_id_t &rhs) const;
@@ -152,6 +154,9 @@ struct file_id_t
     bool operator<(const file_id_t &rhs) const;
     
     static file_id_t file_id_from_stat(const struct stat *buf);
+    
+    private:
+    int compare_file_id(const file_id_t &rhs) const;
 };
 
 file_id_t file_id_for_fd(int fd);