Increase precision of clocks in clock_time_get on Windows #182
Conversation
|
This has a conflict now. |
ospencer
force-pushed
the
oscar/increase-windows-clock-times-precision
branch
from
55f4eb6
to
03c6435
Compare
|
@cjihrig This should be all set, thanks. |
|
@cjihrig Will you be able to cut a release with both these fixes and get them upstreamed into node 19? We're planning to recommend node 19+ WASI support in Grain. |
|
As a heads up here, the process and thread clocks are currently planned to be removed from future versions of WASI, because on implementations where there is not a one-to-one relationship between a wasm instance and a host process, it's prohibitively expensive to implement them. If you have use cases which depend on these clocks, please consider filing an issue in the wasi-clocks repo, where we can discuss how we might accomodate such use cases in a way that all WASI implementations can support. |
|
@sunfishcode I don't think we have any direct need for them, but Grain is a WASI-compatible language so we have bindings for all of preview1 and discovered this bug. Updating uvwasi to preview2 is outlined in #59 |
|
(It also looks like someone needs to kick the CI because it's been running for 3 hours) |
|
Regarding the CI - I kicked the CI. It looks like GitHub Actions had some issue earlier on Windows. It looks like everything is fine now. Regarding the release - yes, I can cut a new release and update Node. It will be released in Node 19 (either the next version or the one after, I'm not sure what the release calendar currently looks like). Regarding the next WASI snapshot - someone needs to step up and do the work. There is a WIP branch here, but it hasn't been updated since Sept 2020. I'm happy to review code, cut releases, etc. but I no longer work on this project. I'm also happy to give the commit bit to anyone working on the project. |
|
Thanks! We didn't know about that. This project is widely used (nodejs, WAMR, Wasm3) so we thought it was actively maintained. I'll try to figure out how we can keep this maintained! Thank you for all your hard work 🙇 |
This PR is rebased on #181.
This increases the precision of the
UVWASI_CLOCK_PROCESS_CPUTIME_IDandUVWASI_CLOCK_THREAD_CPUTIME_IDclocks on Windows. The raw values fromGetProcessTimesandGetThreadTimesare in units of 100 nanoseconds, which matches the reported resolution returned fromuvwasi_clock_time_get.I can't find any documentation on it, but in my testing I only saw an actual precision of about 1000 nanoseconds, which I suppose makes sense if the process/thread times are counted as microseconds.