From 697e22caa49716369dff6c86461b94fe10b0a009 Mon Sep 17 00:00:00 2001
From: r00ster91 <r00ster91@proton.me>
Date: Thu, 6 Oct 2022 08:50:03 +0200
Subject: [PATCH] fix: resolve data race in std.Progress.maybeRefresh()

It seems we can simply lock the update mutex a little earlier.
---
 lib/std/Progress.zig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/std/Progress.zig b/lib/std/Progress.zig
index fe2f7bc795..61c1ee2a32 100644
--- 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;