Skip to content

Revise the documentation for WASI 0.3.0's tcp-socket::receive. #112

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jan 22, 2025

Conversation

sunfishcode
Copy link
Member

receive no longer returns its own result, so update the text that says it fails if receive has already been called. Instead say that a new stream that immediately fails is returned.

And, be specific about how the stream and the future to say that either both succeed or both fail. This eliminates ambiguity about whether the stream could report a failure independently of the future.

`receive` no longer returns its own `result`, so update the text that
says it fails if `receive` has already been called. Instead say that
a new stream that immediately fails is returned.

And, be specific about how the `stream` and the `future` to say that
either both succeed or both fail. This eliminates ambiguity about
whether the `stream` could report a failure independently of the
`future`.
@sunfishcode
Copy link
Member Author

For additional context here, there's discussion in #111 about migrating tuple<stream<u8>, future<result<_, error-code>>> to stream<u8, result<_, error-code>> in the future, however it's likely the design of stream<T, U> would be that it would only produce a U if the stream otherwise closed successfully, which would mean that the result<_, U> could report failure when the stream itself reported success. That's unfortunate if one is able to split a stream<T> out of a stream<T, U> because it means consumers of the stream<T> wouldn't get to see that other failure.

So instead of evolving toward stream<T, result<U, E>>, we should consider evolving toward stream<T, U, E>, where U is the success value and E is the failure value. That way, if one splits a stream<T, U, E>, one would get a stream<T, _, _> which could continue to carry the full success/failure status.

This PR anticipates that evolution by specifying that we only have one success/failure condition.

@sunfishcode
Copy link
Member Author

If this is accepted, I'd plan to update wasi-filesystem's corresponding read function in a similar way.

@badeend
Copy link
Collaborator

badeend commented Jan 22, 2025

Looks good to me. Thanks!


So instead of evolving toward stream<T, result<U, E>>, we should consider evolving toward stream<T, U, E> (...)

Is this already being tracked somewhere, aside from this PR?

@badeend badeend merged commit 8069eb9 into WebAssembly:main Jan 22, 2025
1 check passed
@sunfishcode sunfishcode deleted the sunfishcode/stream-failure branch January 22, 2025 19:28
@sunfishcode
Copy link
Member Author

So instead of evolving toward stream<T, result<U, E>>, we should consider evolving toward stream<T, U, E> (...)

Is this already being tracked somewhere, aside from this PR?

Not yet; the idea only just came up a few days ago. Luke mentioned it here and included it in his presentation here, though it's still a very rough idea at this point.

sunfishcode added a commit to WebAssembly/wasi-filesystem that referenced this pull request Feb 8, 2025
Similar to WebAssembly/wasi-sockets#112, revise the description of
`read` to clarify the relationship between the `stream` and the
`future`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants