Skip to content
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

Odd milliseconds vs nanoseconds discrepancy in the Atomics.wait API #175

Closed
juj opened this issue Jan 15, 2021 · 2 comments
Closed

Odd milliseconds vs nanoseconds discrepancy in the Atomics.wait API #175

juj opened this issue Jan 15, 2021 · 2 comments

Comments

@juj
Copy link

juj commented Jan 15, 2021

The functions Atomics.wait() and Atomics.waitAsync use timeout values in millisecond units:

However, the same Atomics wait operations on the wasm side via memory.atomic.wait32 and memory.atomic.wait64 specify timeout values in nanosecond units:

This inconsistency feels a bit odd, so wanted to double check if that was intentional in the spec to utilize the different units?

juj added a commit to juj/emscripten that referenced this issue Jan 15, 2021
…. (JS side Atomics.wait API uses milliseconds - WebAssembly/threads#175 but not the wasm side opcodes). Add tests for emscripten_lock API.
@conrad-watt
Copy link
Collaborator

It was a deliberate decision a while ago, you can read the previous discussion here
#36

One of the posts in that issue has a dead link to the relevant meeting notes, here's the fixed link
https://github.com/WebAssembly/meetings/blob/master/main/2017/CG-07.md#threads

@juj
Copy link
Author

juj commented Jan 15, 2021

Thanks for the quick answer, very informative thread, and looks like it was deliberate indeed.

@juj juj closed this as completed Jan 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants