Stream: git-wasmtime

Topic: wasmtime / PR #12629 fix `Pollable` impl for `OutgoingDat...


view this post on Zulip Wasmtime GitHub notifications bot (Feb 20 2026 at 19:26):

dicej requested wasmtime-wasi-reviewers for a review on PR #12629.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 20 2026 at 19:26):

dicej opened PR #12629 from dicej:outgoing-datagram-stream-pollable-fix to bytecodealliance:main:

Previously, OutgoingDatagramStream used its send_state field to determine whether the socket was ready for writing without necessarily polling the tokio::net::UdpSocket. The underlying assumption was that a freshly-bound socket would be immediately ready for writing, but that's not true for tokio. tokio assumes a socket is not ready for _anything_ by default and relies on e.g. epoll to tell it otherwise.

In practice, this meant the Pollable::ready impl for OutgoingDatagramStream would resolve immediately for a fresh socket, leaving the guest to race with tokio's use of epoll. Usually, tokio won and all was well, but occasionally it lost and the OutgoingDatagramStream::send call would return Ok(0) (meaning "would block") leaving the guest confused since it was just told that the socket was ready for writing.

This commit removes SendState entirely, relying exclusively on tokio::net::UdpSocket::ready for the Pollable and check_send implementations. As a side effect, we no longer attempt to prevent the guest from sending more datagrams than check_send indicated since the number returned by check_send is only a guess anyway, and tokio will push back if it needs to. For p3, the whole check_send/send pattern is gone, so we won't need to concern ourselves with it going forward.

Fixes #12612

<!--
Please make sure you include the following information:

Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.html

Please ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->

view this post on Zulip Wasmtime GitHub notifications bot (Feb 20 2026 at 19:26):

dicej requested cfallin for a review on PR #12629.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 20 2026 at 19:26):

dicej requested wasmtime-core-reviewers for a review on PR #12629.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 20 2026 at 19:26):

dicej requested alexcrichton for a review on PR #12629.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 20 2026 at 19:27):

dicej unassigned cfallin from PR #12629 fix Pollable impl for OutgoingDatagramStream.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 20 2026 at 19:27):

dicej commented on PR #12629:

cc @badeend in case you're interested

view this post on Zulip Wasmtime GitHub notifications bot (Feb 20 2026 at 19:30):

alexcrichton submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 20 2026 at 19:30):

alexcrichton created PR review comment:

Could this additionally debug_assert! that count == 0?

view this post on Zulip Wasmtime GitHub notifications bot (Feb 20 2026 at 19:30):

alexcrichton commented on PR #12629:

Also, if you're up for it, I think it'd be good to test this on p3 too (semantically at least)

view this post on Zulip Wasmtime GitHub notifications bot (Feb 20 2026 at 20:16):

dicej updated PR #12629.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 20 2026 at 20:16):

dicej has enabled auto merge for PR #12629.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 20 2026 at 20:30):

dicej added PR #12629 fix Pollable impl for OutgoingDatagramStream to the merge queue

view this post on Zulip Wasmtime GitHub notifications bot (Feb 20 2026 at 20:53):

dicej merged PR #12629.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 20 2026 at 20:53):

dicej removed PR #12629 fix Pollable impl for OutgoingDatagramStream from the merge queue

view this post on Zulip Wasmtime GitHub notifications bot (Feb 21 2026 at 07:49):

badeend commented on PR #12629:

As a side effect, we no longer attempt to prevent the guest from sending more datagrams than check_send indicated since the number returned by check_send is only a guess anyway

@dicej This violates the P2 spec:

Each call to send must be permitted by a preceding check-send. Implementations must trap if either check-send was not called or datagrams contains more items than check-send permitted.

Can the check be reintroduced?

view this post on Zulip Wasmtime GitHub notifications bot (Feb 21 2026 at 18:06):

dicej commented on PR #12629:

@dicej This violates the P2 spec:

Each call to send must be permitted by a preceding check-send. Implementations must trap if either check-send was not called or datagrams contains more items than check-send permitted.

Can the check be reintroduced?

:face_palm: Yes, I'll do that on Monday. Thanks for catching that.


Last updated: Feb 24 2026 at 04:36 UTC