Skip to content

wasip3: Finish nonblocking I/O implementation for TCP#782

Merged
alexcrichton merged 6 commits intoWebAssembly:mainfrom
alexcrichton:tcp-nonblocking
Apr 13, 2026
Merged

wasip3: Finish nonblocking I/O implementation for TCP#782
alexcrichton merged 6 commits intoWebAssembly:mainfrom
alexcrichton:tcp-nonblocking

Conversation

@alexcrichton
Copy link
Copy Markdown
Collaborator

This commit fills out the final bits of nonblocking I/O for TCP sockets. This necessitates an implementation of nonblocking I/O for stream<u8> on both the reading and the writing side of things. Additionally things like TCP accepts now work, too. All tests are now passing on the WASIp3 target and the FAILP3 directive is now removed since it's no longer necessary.

The internals of the implementation here are pretty gnarly. This is due to the need to bridge the readiness-based-model of poll with the completion-based model of the component model. This implementation contains optimizations for 0-length reads/writes to use those to signal readiness if the host supports that, but this falls back to internally-buffered reads/writes if that is not supported.

This should resolve all remaining TODOs for WASIp3 that I know of at least in wasi-libc, so after this it'd be switching to bug-finding mode and handling bug reports as projects are compiled with wasip3.

This commit fills out the final bits of nonblocking I/O for TCP sockets.
This necessitates an implementation of nonblocking I/O for `stream<u8>`
on both the reading and the writing side of things. Additionally things
like TCP accepts now work, too. All tests are now passing on the WASIp3
target and the `FAILP3` directive is now removed since it's no longer
necessary.

The internals of the implementation here are pretty gnarly. This is due
to the need to bridge the readiness-based-model of `poll` with the
completion-based model of the component model. This implementation
contains optimizations for 0-length reads/writes to use those to signal
readiness if the host supports that, but this falls back to
internally-buffered reads/writes if that is not supported.

This should resolve all remaining TODOs for WASIp3 that I know of at
least in wasi-libc, so after this it'd be switching to bug-finding mode
and handling bug reports as projects are compiled with wasip3.
@alexcrichton
Copy link
Copy Markdown
Collaborator Author

cc @badeend, would you be willing to take a look at this? I realize that you may not be the most familiar with this code so it's totally fine if you'd rather not, too.

@alexcrichton alexcrichton requested a review from dicej April 9, 2026 01:13
Copy link
Copy Markdown
Collaborator

@dicej dicej left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎉

Comment thread libc-bottom-half/sources/file_utils.c Outdated
Comment thread libc-bottom-half/sources/file_utils.c Outdated
Co-authored-by: Joel Dice <joel.dice@akamai.com>
@alexcrichton alexcrichton merged commit 5885dd9 into WebAssembly:main Apr 13, 2026
32 checks passed
@alexcrichton alexcrichton deleted the tcp-nonblocking branch April 13, 2026 20:14
@alexcrichton
Copy link
Copy Markdown
Collaborator Author

I'm going to go ahead and merge this @badeend but I'd still value your input if you get a chance in the future to take a look, happy to have follow-ups!

Copy link
Copy Markdown
Member

@badeend badeend left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@alexcrichton I reviewed this change and found a few potential issues. Note that I'v only read the code and haven’t confirmed every suspicion. It could very well be that things are already handled properly, but just some place else that Ive missed.

Comment thread libc-bottom-half/sources/file_utils.c
Comment thread libc-bottom-half/sources/tcp.c
Comment thread libc-bottom-half/sources/file_utils.c
Comment thread libc-bottom-half/sources/file_utils.c
Comment thread libc-bottom-half/sources/file_utils.c
Comment thread libc-bottom-half/sources/file_utils.c
Comment thread libc-bottom-half/sources/tcp.c
Comment thread libc-bottom-half/sources/file_utils.c
Comment thread libc-bottom-half/sources/tcp.c
Comment thread libc-bottom-half/sources/tcp.c
alexcrichton added a commit that referenced this pull request Apr 21, 2026
alexcrichton added a commit that referenced this pull request Apr 21, 2026
alexcrichton added a commit that referenced this pull request Apr 22, 2026
This commit fixes mistakes from #782 where the fallback code for
buffering writes wasn't handled properly. Specifically when a completion
event came in through `poll` it didn't fully update the internal state
of the stream, such as kicking off further writes or cleaning up the
internal buffer. This is fixed by refactoring the logic already present
during a normal `write` to get executed in this event.

Testing this is unfortunately not trivial. There aren't really all that
many streams we have access to natively in Wasmtime, and TCP is "well
behaved" and doesn't execute any of these fallbacks anyway. The closest
way to test this is filesystem-based streams, but Wasmtime's default
behavior is to lie and just do blocking operations on these streams
regardless. Through changes in Wasmtime, and flags to Wasmtime, however,
it's possible to Wasmtime in a mode where filesystem streams are "ill
behaved" where zero-length reads don't signal readiness, triggering
these fallback paths. With those changes the added test here, and minor
additionally support for nonblocking reads/writes, exercise these paths
and triggers the previous bug.
@alexcrichton
Copy link
Copy Markdown
Collaborator Author

Thanks @badeend! I believe I've handled all your comments now through these PRs:

#793
#792
#791
#790
#789
bytecodealliance/wasmtime#13163
#788
#787
bytecodealliance/wasmtime#13158
#786
#785

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

Successfully merging this pull request may close these issues.

3 participants