-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The monotonic clock may be too underspecified #47
Comments
Thanks for posting this! I'm not sure yet what I think. Here are some initial notes. At first glance, this seems to align with the spirit of WASI: in general, we don't want guest code to be aware of "the system" unless it has a specific need to, so it's tempting to want "the system is suspended" to default to looking the same as the system just running really slow for a while, which could happen for any number of reasons that the guest wouldn't know about. Some time ago, Linux changed its So overall, this seems like it might be a good idea. The main complication I see so far is that not all popular host OS's have a monotonic clock that counts time suspended, and even on platforms which do, not all the APIs support it. For example, Linux has its |
The monotonic clock as it stands right now is likely too underspecified in what it is measuring and should possibly be split into two separate clocks. This problem is something that is fairly unknown, but eventually has bitten basically every operating system, browser and programming language and I would want to prevent WASI from running into the same issue before it's too late.
The thing is that a lot of programs want to measure the time they are actively running, whereas a lot of programs want to measure the real world time that is happening. That sounds like it is the same thing, but it actually differs when the host is suspended (phone screen turned off, laptop closed, operating system suspended, wasm runtime suspending the guest module for a while, ...).
A lot of the time you want to measure the actual real world time that has progressed, for example when you have some sort of server API token that expires in 60 minutes, then turning off the screen of my phone for a while shouldn't mess with the time measurement.
However there are also cases where an application wants to only measure "its perceived time". The easiest example would be in a game, where me turning off the screen of my phone and turning it back 20 minutes later shouldn't cause the physics to freak out because a single frame took 20 minutes (usually the velocity vectors are multiplied by the time a frame takes).
Whether this second case is worth supporting in WASI is debatable, but it's important to at least very clearly state the difference in the documentation, such that runtime implementations don't accidentally implement the wrong thing. In fact the WebAssembly runtimes (such as wasmtime) already inconsistently implement this as either "real time" or "perceived time".
References:
https://lwn.net/Articles/428176/
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d6ed449afdb38f89a7b38ec50e367559e1b8f71f
https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable/+/a3ed0e4393d6885b4af7ce84b437dc696490a530
rust-lang/rust#87906
golang/go#24595
w3c/hr-time#115
https://bugs.chromium.org/p/chromium/issues/detail?id=1206450
https://bugzilla.mozilla.org/show_bug.cgi?id=1709767
https://bugs.webkit.org/show_bug.cgi?id=225610
The text was updated successfully, but these errors were encountered: