Move atomics.wait path for emscripten_futex_wait to native code. NFC#15742
Merged
Move atomics.wait path for emscripten_futex_wait to native code. NFC#15742
emscripten_futex_wait to native code. NFC#15742Conversation
Collaborator
Author
|
View diff with "ignore whitespace" |
sbc100
force-pushed
the
futex_wait_native
branch
2 times, most recently
from
d676cee to
149b123
Compare
sbc100
force-pushed
the
futex_wait_native
branch
from
149b123 to
bba98f7
Compare
tlively
approved these changes
Dec 10, 2021
Member
tlively
left a comment
tlively
left a comment
There was a problem hiding this comment.
Awesome! I'm happy to be able to use the Wasm instruction for waiting.
sbc100
force-pushed
the
futex_wait_native
branch
from
bba98f7 to
688986c
Compare
sbc100
added a commit
to WebAssembly/binaryen
that referenced
this pull request
Dec 10, 2021
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
sbc100
added a commit
to WebAssembly/binaryen
that referenced
this pull request
Dec 11, 2021
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
kleisauke
approved these changes
Dec 11, 2021
Collaborator
kleisauke
left a comment
kleisauke
left a comment
There was a problem hiding this comment.
LGTM! I left a small question as an inline comment.
sbc100
added a commit
to WebAssembly/binaryen
that referenced
this pull request
Dec 11, 2021
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
sbc100
force-pushed
the
futex_wait_native
branch
2 times, most recently
from
2b3c092 to
a30cc15
Compare
juj
reviewed
Dec 12, 2021
sbc100
force-pushed
the
futex_wait_native
branch
from
a30cc15 to
940ee73
Compare
sbc100
changed the title
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.
sbc100
force-pushed
the
futex_wait_native
branch
from
940ee73 to
09c219d
Compare
mmarczell-graphisoft
pushed a commit
to GRAPHISOFT/emscripten
that referenced
this pull request
Jan 5, 2022
…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.
sbc100
added a commit
that referenced
this pull request
Dec 19, 2022
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.
sbc100
added a commit
that referenced
this pull request
Dec 19, 2022
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.
sbc100
added a commit
that referenced
this pull request
Dec 19, 2022
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.
sbc100
added a commit
that referenced
this pull request
Dec 19, 2022
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.
sbc100
added a commit
that referenced
this pull request
Dec 20, 2022
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.
sbc100
added a commit
that referenced
this pull request
Dec 23, 2022
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.
sbc100
added a commit
that referenced
this pull request
Dec 26, 2022
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.
sbc100
added a commit
that referenced
this pull request
Dec 26, 2022
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add a new WebAssembly global to the native side that signals if
the current thread can use
atomics.waitand use this to implementthe
atomics.waitversion 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