-
Notifications
You must be signed in to change notification settings - Fork 22
Add an initial witx file for I/O Streams. #4
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great!
I have a few non-blocking nits, such as missing comments and typos, and a question about the read_status
, but this is looking great!
;;; amount of data has been consumed. The data is returned successfully | ||
;;; with a `$push`, and the next `read` or `skip` call will report the | ||
;;; failure. | ||
$push |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should there be separate statuses here for streams that model the PUSH
flag / flushing (like TCP) and a different one for indicating a possible failure?
What is the thinking behind having the same status for both?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are good questions :-). I filed #9 to think about these further.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
We can continue the discussion about the $push
status in #9, and I'm in favor of merging sooner rather than later, so we can iterate on the API.
This also extends the ABI validator to allow multiple return types, as are used in the I/O streams interface.
And, add more comments about how errors and end-of-stream work.
Thinking about this more, returning the number of bytes along with a failure to indicate a partial success makes user code more complex. So I'm now thinking it's better to just have the interface be a single result which either succeeds or fails. This also removes dependence on the `$errno` type, as I/O types don't need the majority of the error values.
This may turn out to be too simplified, but we can iterator on it.
8bec7e3
to
1cd1b28
Compare
This also extends the ABI validator to allow multiple return types, as
are used in the I/O streams interface.