You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 25, 2025. It is now read-only.
I'm debugging a flaky test right now in Wasmtime's CI, and one interesting behavior I'm seeing is that there's a blocking_receive helper for UDP sockets which tries to wait in a loop, and I was going to add an upper limit to the loop to help time it out. This loop, however, never blocks. The socket is always ready for I/O, despite the receive call not actually returning anything. Still trying to figure out the latter, but for the former I believe one issue is that the subscribe for UDP sockets is either readable or writable readiness right now so if a socket is acting as a server then there's no way to block it for read readiness since it's always writable if you're not writing.
I'm debugging a flaky test right now in Wasmtime's CI, and one interesting behavior I'm seeing is that there's a
blocking_receivehelper for UDP sockets which tries to wait in a loop, and I was going to add an upper limit to the loop to help time it out. This loop, however, never blocks. The socket is always ready for I/O, despite thereceivecall not actually returning anything. Still trying to figure out the latter, but for the former I believe one issue is that thesubscribefor UDP sockets is either readable or writable readiness right now so if a socket is acting as a server then there's no way to block it for read readiness since it's always writable if you're not writing.