-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Move atomics.wait path for emscripten_futex_wait
to native code. NFC
#15742
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
Conversation
View diff with "ignore whitespace" |
d676cee
to
149b123
Compare
149b123
to
bba98f7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome! I'm happy to be able to use the Wasm instruction for waiting.
bba98f7
to
688986c
Compare
Also, fix bug where pointer was being used direcltly to index into Int32Array. I suppose this code had basically zero users until I tried to land this change in emscripten: emscripten-core/emscripten#15742
Also, fix bug where pointer was being used direcltly to index into Int32Array. I suppose this code had basically zero users until I tried to land this change in emscripten: emscripten-core/emscripten#15742
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! I left a small question as an inline comment.
Also, fix bug where pointer was being used direcltly to index into Int32Array. I suppose this code had basically zero users until I tried to land this change in emscripten: emscripten-core/emscripten#15742
2b3c092
to
a30cc15
Compare
a30cc15
to
940ee73
Compare
emscripten_thread_can_block
function and use it in emscripten_futex_wait
. NFCemscripten_futex_wait
to native code. NFC
Add a new WebAssembly global to the native side that signals if the current thread can use `atomics.wait` and use this to implement the `atomics.wait` version of `emscripten_futex_wait`. The non-blocking/busy-looping path is still implemented in JS for now. It could potentially be moved as a followup.
940ee73
to
09c219d
Compare
…NFC (emscripten-core#15742) Add a new WebAssembly global to the native side that signals if the current thread can use `atomics.wait` and use this to implement the `atomics.wait` version of `emscripten_futex_wait`. The non-blocking/busy-looping path is still implemented in JS for now. It could potentially be moved as a followup.
When I ported this code from JS back in #15742 I mistakenly changed the semantics here. This change restores the previous behaviour of using atomic.wait except in on the main browser thread. The `futex_wait_busy` can clearly only be used a single main thread and is not appropriate for using in cases where there are other threads in the system that also don't support `atomic.wait` (such as IIUC audio worklets). To support that case we would need a different busy wait function that didn't depend on some global singleton like _emscripten_main_thread_futex.
When I ported this code from JS back in #15742 I mistakenly changed the semantics here. This change restores the previous behaviour of using atomic.wait except in on the main browser thread. The `futex_wait_busy` can clearly only be used a single main thread and is not appropriate for using in cases where there are other threads in the system that also don't support `atomic.wait` (such as IIUC audio worklets). To support that case we would need a different busy wait function that didn't depend on some global singleton like _emscripten_main_thread_futex.
When I ported this code from JS back in #15742 I mistakenly changed the semantics here. This change restores the previous behaviour of using atomic.wait except in on the main browser thread. The `futex_wait_busy` can clearly only be used a single main thread and is not appropriate for using in cases where there are other threads in the system that also don't support `atomic.wait` (such as IIUC audio worklets). To support that case we would need a different busy wait function that didn't depend on some global singleton like _emscripten_main_thread_futex.
When I ported this code from JS back in #15742 I mistakenly changed the semantics here. This change restores the previous behaviour of using atomic.wait except in on the main browser thread. The `futex_wait_busy` can clearly only be used a single main thread and is not appropriate for using in cases where there are other threads in the system that also don't support `atomic.wait` (such as IIUC audio worklets). To support that case we would need a different busy wait function that didn't depend on some global singleton like _emscripten_main_thread_futex.
When I ported this code from JS back in #15742 I mistakenly changed the semantics here. This change restores the previous behaviour of using atomic.wait except in on the main browser thread. The `futex_wait_busy` can clearly only be used a single main thread and is not appropriate for using in cases where there are other threads in the system that also don't support `atomic.wait` (such as IIUC audio worklets). To support that case we would need a different busy wait function that didn't depend on some global singleton like _emscripten_main_thread_futex.
When I ported this code from JS back in #15742 I mistakenly changed the semantics here. This change restores the previous behaviour of using atomic.wait except in on the main browser thread. The `futex_wait_busy` can clearly only be used a single main thread and is not appropriate for using in cases where there are other threads in the system that also don't support `atomic.wait` (such as IIUC audio worklets). To support that case we would need a different busy wait function that didn't depend on some global singleton like _emscripten_main_thread_futex.
When I ported this code from JS back in #15742 I mistakenly changed the semantics here. This change restores the previous behaviour of using atomic.wait except in on the main browser thread. The `futex_wait_busy` can clearly only be used a single main thread and is not appropriate for using in cases where there are other threads in the system that also don't support `atomic.wait` (such as IIUC audio worklets). To support that case we would need a different busy wait function that didn't depend on some global singleton like _emscripten_main_thread_futex.
When I ported this code from JS back in #15742 I mistakenly changed the semantics here. This change restores the previous behaviour of using atomic.wait except in on the main browser thread. The `futex_wait_busy` can clearly only be used a single main thread and is not appropriate for using in cases where there are other threads in the system that also don't support `atomic.wait` (such as IIUC audio worklets). To support that case we would need a different busy wait function that didn't depend on some global singleton like _emscripten_main_thread_futex.
Add a new WebAssembly global to the native side that signals if
the current thread can use
atomics.wait
and use this to implementthe
atomics.wait
version ofemscripten_futex_wait
.The non-blocking/busy-looping path is still implemented in JS
for now. It could potentially be moved as a followup.
See #15061