Rohit Kulshreshtha
Rohit Kulshreshtha
The WASM SystemTime implementation through the `instant` crate does the following for `duration_since`: ```rust pub fn duration_since(&self, earlier: SystemTime) -> Result { let dur_ms = self.0 - earlier.0; if dur_ms...
This isn't a choice-of-library issue. My main point is that evaluating that some wall-clock time has elapsed after `defer_tick` is always going to be flaky. It worked in the past...
Oh. I didn't know it had the check completely backward. I suspected it's a millisecond-grained timestamp that makes equal timestamp fails (so >= or ). I agree with replacing it....
Yup. It passes on my laptop. It may succeed if the test is re-run. Disabling auto-merge.
For Hybrid-Logical clock? I need the wall clock time. Instant is not wall clock time - it's an offset from some arbitrary event, and systems may not even agree on...
Fixed. https://github.com/hydro-project/hydroflow/pull/1196 For the future: https://github.com/hydro-project/hydroflow/issues/1202
That’s a good point. What do we think about the split in executor responsibilities between tokio and hydro flow? On Wed, May 8, 2024 at 3:58 PM Shadaj Laddad ***@***.***>...
`tokio::time::Instant` is similar to `std::time::Instant` - it is opaque, only meaningful when compared to another instant, and not a wall-clock timestamp.
https://github.com/hydro-project/hydroflow/pull/1217
Next steps: Check with David re: metrics.