Implement only poll() and not select() in JS #25990
Merged
Conversation
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
ktock
reviewed
Dec 22, 2025
sbc100
force-pushed
the
poll_blocking
branch
2 times, most recently
from
b8d0829 to
9ec78d9
Compare
sbc100
force-pushed
the
poll_blocking
branch
8 times, most recently
from
d44829d to
fa8fc29
Compare
sbc100
force-pushed
the
poll_blocking
branch
3 times, most recently
from
7201094 to
4f8ad00
Compare
sbc100
force-pushed
the
poll_blocking
branch
from
4f8ad00 to
169777d
Compare
aheejin
reviewed
Dec 23, 2025
Member
aheejin
left a comment
aheejin
left a comment
There was a problem hiding this comment.
Looks like a nice simplification! A few nits below. I can't "approve" because it is set to auto-merge...
This change improves the implementation of poll() to support blocking when called from threads (see emscripten-core#25523) and moves the select-based-on-poll implemenation from being wasmfs specific to be always being used.
sbc100
force-pushed
the
poll_blocking
branch
from
169777d to
2c29316
Compare
sbc100
added a commit
to sbc100/emscripten
that referenced
this pull request
Dec 23, 2025
This new mode allows the proxied work itself to be asynchronous (i.e. return a promise). We can use this new mode to replace the bespoke proxying code that exists for dlsync as well as the poll system call. For the poll system call this bespoke code was added in emscripten-core#25523 and emscripten-core#25990, but can now be completely removed. I'm still not sure how best to name this new mode, and I imagine it will be fairly rare that it is used. One downside of this new mode is that the proxied work requires the main thread event loop to run. Unlike the synchronous proxied work that can complete even when we are deeply nested.
sbc100
added a commit
to sbc100/emscripten
that referenced
this pull request
Dec 23, 2025
This new mode allows the proxied work itself to be asynchronous (i.e. return a promise). We can use this new mode to replace the bespoke proxying code that exists for dlsync as well as the poll system call. For the poll system call this bespoke code was added in emscripten-core#25523 and emscripten-core#25990, but can now be completely removed. I'm still not sure how best to name this new mode, and I imagine it will be fairly rare that it is used. One downside of this new mode is that the proxied work requires the main thread event loop to run. Unlike the synchronous proxied work that can complete even when we are deeply nested.
sbc100
added a commit
to sbc100/emscripten
that referenced
this pull request
Dec 23, 2025
This new mode allows the proxied work itself to be asynchronous (i.e. return a promise). We can use this new mode to replace the bespoke proxying code that exists for dlsync as well as the poll system call. For the poll system call this bespoke code was added in emscripten-core#25523 and emscripten-core#25990, but can now be completely removed. I'm still not sure how best to name this new mode, and I imagine it will be fairly rare that it is used. One downside of this new mode is that the proxied work requires the main thread event loop to run. Unlike the synchronous proxied work that can complete even when we are deeply nested.
sbc100
added a commit
to sbc100/emscripten
that referenced
this pull request
Dec 23, 2025
This new mode allows the proxied work itself to be asynchronous (i.e. return a promise). We can use this new mode to replace the bespoke proxying code that exists for `dlsync` as well as the `poll` system call. For the poll system call this bespoke code was added in emscripten-core#25523 and emscripten-core#25990, but can now be completely removed. In addition to this, because the `poll` syscall is now marked as `__async` it automatically works under JSPI too. One downside of this new mode is that the proxied work requires the main thread event loop to run. Unlike the synchronous proxied work that can complete even when we are deeply nested.
sbc100
added a commit
to sbc100/emscripten
that referenced
this pull request
Dec 23, 2025
This new mode allows the proxied work itself to be asynchronous (i.e. return a promise). The new behaviour is triggered by marking a functions as both `__proxy: 'sync'` and also `__async: true`. We can use this new mode to replace the bespoke proxying code that exists for `dlsync` as well as the `poll` system call. For the poll system call this bespoke code was added in emscripten-core#25523 and emscripten-core#25990, but can now be completely removed. In addition to this, because the `poll` syscall is now marked as `__async` it automatically works under JSPI too. One downside of this new mode is that the proxied work requires the main thread event loop to run. Unlike the synchronous proxied work that can complete even when we are deeply nested. Fixes: emscripten-core#25970
sbc100
added a commit
to sbc100/emscripten
that referenced
this pull request
Dec 23, 2025
This new mode allows the proxied work itself to be asynchronous (i.e. return a promise). The new behaviour is triggered by marking a functions as both `__proxy: 'sync'` and also `__async: true`. We can use this new mode to replace the bespoke proxying code that exists for `dlsync` as well as the `poll` system call. For the poll system call this bespoke code was added in emscripten-core#25523 and emscripten-core#25990, but can now be completely removed. In addition to this, because the `poll` syscall is now marked as `__async` it automatically works under JSPI too. One downside of this new mode is that the proxied work requires the main thread event loop to run. Unlike the synchronous proxied work that can complete even when we are deeply nested. Fixes: emscripten-core#25970
sbc100
added a commit
to sbc100/emscripten
that referenced
this pull request
Dec 23, 2025
This new mode allows the proxied work itself to be asynchronous (i.e. return a promise). The new behaviour is triggered by marking a functions as both `__proxy: 'sync'` and also `__async: true`. We can use this new mode to replace the bespoke proxying code that exists for `dlsync` as well as the `poll` system call. For the poll system call this bespoke code was added in emscripten-core#25523 and emscripten-core#25990, but can now be completely removed. In addition to this, because the `poll` syscall is now marked as `__async` it automatically works under JSPI too. One downside of this new mode is that the proxied work requires the main thread event loop to run. Unlike the synchronous proxied work that can complete even when we are deeply nested. Fixes: emscripten-core#25970
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 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.
This change improves the implementation of poll() to support blocking when called from threads (see #25523) and moves the select-based-on-poll implementation from being wasmfs specific to be always being used.
Also, add testing for blocking version of poll by duplicating the blocking select test.