authorgravatar for andrew@ziglang.orgAndrew Kelley <andrew@ziglang.org> 2020-12-21 20:44:36-07:00
committergravatar for andrew@ziglang.orgAndrew Kelley <andrew@ziglang.org> 2020-12-23 13:36:21-08:00
logf4d82f0ad6b10881c0831595ad0e957094892a45
tree6fadc97bb03a3c2e0664608e92f6c280404a9003
parent485ec0884ff81a23ca5460a6d07d4e2c2d6b81cb

std.Progress: work around time going backwards

1 files changed, 3 insertions(+), 0 deletions(-)

lib/std/Progress.zig+3
...@@ -160,6 +160,9 @@ pub fn maybeRefresh(self: *Progress) void {...@@ -160,6 +160,9 @@ pub fn maybeRefresh(self: *Progress) void {
160 if (now < self.initial_delay_ns) return;160 if (now < self.initial_delay_ns) return;
161 const held = self.update_lock.tryAcquire() orelse return;161 const held = self.update_lock.tryAcquire() orelse return;
162 defer held.release();162 defer held.release();
163 // TODO I have observed this to happen sometimes. I think we need to follow Rust's
164 // lead and guarantee monotonically increasing times in the std lib itself.
165 if (now < self.prev_refresh_timestamp) return;
163 if (now - self.prev_refresh_timestamp < self.refresh_rate_ns) return;166 if (now - self.prev_refresh_timestamp < self.refresh_rate_ns) return;
164 return self.refreshWithHeldLock();167 return self.refreshWithHeldLock();
165}168}