Decouple WASIp2 sockets from WasiFd #131449
Merged
Conversation
This file contains 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
rustbot
added
O-wasi
|
I'm happy to take on review of this |
|
@bors: r+ Looks great to me, thanks! It's ok to change |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Oct 10, 2024
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#123951 (Reserve guarded string literals (RFC 3593)) - rust-lang#130827 (Library: Rename "object safe" to "dyn compatible") - rust-lang#131383 (Add docs about slicing slices at the ends) - rust-lang#131403 (Fix needless_lifetimes in rustc_serialize) - rust-lang#131417 (Fix methods alignment on mobile) - rust-lang#131449 (Decouple WASIp2 sockets from WasiFd) - rust-lang#131462 (Mention allocation errors for `open_buffered`) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Oct 10, 2024
Rollup merge of rust-lang#131449 - nickrum:wasip2-net-decouple-fd, r=alexcrichton Decouple WASIp2 sockets from WasiFd This is a follow up to rust-lang#129638, decoupling WASIp2's socket implementation from WASIp1's `WasiFd` as discussed with `@alexcrichton.` Quite a few trait implementations in `std::os::fd` rely on the fact that there is an additional layer of abstraction between `Socket` and `OwnedFd`. I thus had to add a thin `WasiSocket` wrapper struct that just "forwards" to `OwnedFd`. Alternatively, I could have added a lot of conditional compilation to `std::os::fd`, which feels even worse. Since `WasiFd::sock_accept` is no longer accessible from `TcpListener` and since WASIp2 has proper support for accepting sockets through `Socket::accept`, the `std::os::wasi::net` module has been removed from WASIp2, which only contains a single `TcpListenerExt` trait with a `sock_accept` method as well as an implementation for `TcpListener`. Let me know if this is an acceptable solution.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 is a follow up to #129638, decoupling WASIp2's socket implementation from WASIp1's
WasiFdas discussed with @alexcrichton.Quite a few trait implementations in
std::os::fdrely on the fact that there is an additional layer of abstraction betweenSocketandOwnedFd. I thus had to add a thinWasiSocketwrapper struct that just "forwards" toOwnedFd. Alternatively, I could have added a lot of conditional compilation tostd::os::fd, which feels even worse.Since
WasiFd::sock_acceptis no longer accessible fromTcpListenerand since WASIp2 has proper support for accepting sockets throughSocket::accept, thestd::os::wasi::netmodule has been removed from WASIp2, which only contains a singleTcpListenerExttrait with asock_acceptmethod as well as an implementation forTcpListener. Let me know if this is an acceptable solution.