zig

commit 697e22caa49716369dff6c86461b94fe10b0a009 (tree)
parent 0b7b4b7e9787a892712e8c1bf31f4c309441afe4
Author: r00ster91 <r00ster91@proton.me>
Date:   Thu,  6 Oct 2022 08:50:03 +0200

fix: resolve data race in std.Progress.maybeRefresh()

It seems we can simply lock the update mutex a little earlier.

Diffstat:
M
lib/std/Progress.zig
 | 
4
++--

1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/std/Progress.zig b/lib/std/Progress.zig
@@ -172,10 +172,10 @@ pub fn start(self: *Progress, name: []const u8, estimated_total_items: usize) *N
 /// Updates the terminal if enough time has passed since last update. Thread-safe.
 pub fn maybeRefresh(self: *Progress) void {
     if (self.timer) |*timer| {
-        const now = timer.read();
-        if (now < self.initial_delay_ns) return;
         if (!self.update_mutex.tryLock()) return;
         defer self.update_mutex.unlock();
+        const now = timer.read();
+        if (now < self.initial_delay_ns) return;
         // TODO I have observed this to happen sometimes. I think we need to follow Rust's
         // lead and guarantee monotonically increasing times in the std lib itself.
         if (now < self.prev_refresh_timestamp) return;