github-actions[bot] commented on issue #4776:
Subscribe to Label Action
cc @kubkon
<details>
This issue or pull request has been labeled: "wasi"Thus the following users have been cc'd because of the following labels:
- kubkon: wasi
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
sunfishcode commented on issue #4776:
Windows disagrees :upside_down_face:
jameysharp commented on issue #4776:
I assume cargo-vet is going to need a delta audit for
system-interface
.
stevelr commented on issue #4776:
I am not sure I see how sock_shutdown is intended to be used if the socket is in use by a wasm module.
Scenario: the host creates a tcp listener socket bound to an address, and adds it to
WasiCtx
as apreopened_socket
. The wasm module creates a listener via the wasi api and calls accept().Sometime later, while wasm module is still waiting on
accept
, the host wants to stop the module. It can't directly callsock_shutdown
because neither TcpListen nor Socket are cloneable, so it can't hold onto a cloned object to call shutdown on it later. If the host kept the u32 file descriptor, it could either recreate a Socket from the fd and call sock_shutdown, or pass the fd to a low-level unix function to close it, which seems extremely non-portable. There is a try_clone and if it succeeds it creates an alias file descriptor, but it's not clear from the documentation if it would work for this purpose.What is the recommended method of closing a socket in this scenario?
sunfishcode commented on issue #4776:
@stevelr shutdown doesn't do a close; it just marks a stream as no longer readable, writeable, or both. The file descriptor remains open. And it isn't required to be called.
The main use case for it that I know is for one side of a socket to declare that it's done writing to a stream and will subsequently only be reading the response.
Last updated: Dec 23 2024 at 12:05 UTC