authorgravatar for r00ster91@proton.meWooster <r00ster91@proton.me> 2022-10-06 08:50:03+02:00
committergravatar for git@vexu.euVeikka Tuominen <git@vexu.eu> 2022-10-11 17:46:39+02:00
log697e22caa49716369dff6c86461b94fe10b0a009
tree2761645335aabff446b12bef97127e23b93ae5b0
parent0b7b4b7e9787a892712e8c1bf31f4c309441afe4

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

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

1 files changed, 2 insertions(+), 2 deletions(-)

lib/std/Progress.zig+2-2
......@@ -172,10 +172,10 @@ pub fn start(self: *Progress, name: []const u8, estimated_total_items: usize) *N
172172/// Updates the terminal if enough time has passed since last update. Thread-safe.
173173pub fn maybeRefresh(self: *Progress) void {
174174 if (self.timer) |*timer| {
175 const now = timer.read();
176 if (now < self.initial_delay_ns) return;
177175 if (!self.update_mutex.tryLock()) return;
178176 defer self.update_mutex.unlock();
177 const now = timer.read();
178 if (now < self.initial_delay_ns) return;
179179 // TODO I have observed this to happen sometimes. I think we need to follow Rust's
180180 // lead and guarantee monotonically increasing times in the std lib itself.
181181 if (now < self.prev_refresh_timestamp) return;