This repository was archived by the owner on Sep 8, 2025. It is now read-only.
Conversation
Signed-off-by: Roman Volosatovs <rvolosatovs@riseup.net>
Signed-off-by: Roman Volosatovs <rvolosatovs@riseup.net>
5d52338 to
64e04a1
Compare
Member
Author
|
|
Signed-off-by: Roman Volosatovs <rvolosatovs@riseup.net>
64e04a1 to
975fa29
Compare
Signed-off-by: Roman Volosatovs <rvolosatovs@riseup.net>
This file contains hidden or 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
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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 on #1 and #17 , which ensures the
wasi:socketsTCP implementation is complete and fully tested using the adapted wasip2 test suite.There's only one item I left a TODO about, which does not seem specific to TCP.
It appears that
SinkExt::closehas no effect on guest streams, which the wasip2 TCP suite tests for. Not sure if that's desired behavior or not, but it does necessarily look like a blocker for me.Note, in current implementation streams (e.g. returned by
listen) are lazy and do not do any work unless they're polled. That means, for example, that calls toconnectandStreamExt::nexton the stream returned bylistenmust happen concurrently. Calling the two in sync order may succeed, but that behavior cannot be depended upon. I believe this aligns with the current async design