ENH Rework streams handling #4035
Merged
Conversation
This file contains 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
This fixes a number problems with the old stream handling: 1. Not possible to set a custom errno (necessary for proper interrupt handling and possibly for other things) 2. Inefficient: in a lot of cases we have data in one buffer and we need it placed into a different buffer, but we have to implement a function that gets one byte out of the source buffer and then call it repeatedly to move one byte at a time to the target buffer. 3. Ease of implementation: in many cases we already have perfectly good buffer manipulation APIs, so if we have direct access to the true source or target buffer we can just use these. See: the node IO code, which got much simpler. This is backwards compatible, so you can still use the old input mechanism or use buffered or raw output. But it adds a new method of directly implementing read/write. For simplicity, we insure that the source/destination buffers are always Uint8Array views that point to exactly the region that is meant to be read/written. Because TypedArrays have support for views, I see no reason APIs should pass around a larger buffer with auxilary offset/length parameters. If you do use the old mechanisms, they are still faster and can correctly support keyboard interrupts. Other than that I think the original behavior is unchanged. I added a lot more test coverage to help ensure that, since the streams tests I wrote before had pretty anemic coverage. I think the read/write APIs are mostly pretty simple to use, with the exception that someone might forget to return the number of bytes read. JavaScript's ordinary behavior coerces the `undefined` to a 0, which leads to an infinite loop where the filesystem repeatedly asks to read/write the same data since it sees no progress. I added a check that writes an error message to the console and sets EIO when undefined is returned so the infinite loop is prevented and the problem is explained.
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
ryanking13
reviewed
Aug 17, 2023
ryanking13
approved these changes
Aug 18, 2023
There was a problem hiding this comment.
Thanks, @hoodmane and sorry for the late review.
I have a few minor comments, otherwise LGTM.
|
Thanks for the detailed review @ryanking13! |
Co-authored-by: Gyeongjae Choi <def6488@gmail.com>
for more information, see https://pre-commit.ci
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 fixes a number problems with the old stream handling:
Not possible to set a custom errno (necessary for proper interrupt handling and possibly for other things)
Inefficient: in a lot of cases we have data in one buffer and we need it placed into a different buffer, but we have to implement a function that gets one byte out of the source buffer and then call it repeatedly to move one byte at a time to the target buffer.
Ease of implementation: in many cases we already have perfectly good buffer manipulation APIs, so if we have direct access to the true source or target buffer we can just use these. See: the node IO code, which got much simpler.
This is backwards compatible, so you can still use the old input mechanism or use buffered or raw output. But it adds a new method of directly implementing read/write. For simplicity, we insure that the source/destination buffers are always Uint8Array views that point to exactly the region that is meant to be read/written. Because TypedArrays have support for views, I see no reason APIs should pass around a larger buffer with auxilary offset/length parameters.
If you do use the old mechanisms, they are still faster and can correctly support keyboard interrupts. Other than that I think the original behavior is unchanged. I added a lot more test coverage to help ensure that, since the streams tests I wrote before had pretty anemic coverage.
I think the read/write APIs are mostly pretty simple to use, with the exception that someone might forget to return the number of bytes read. JavaScript's ordinary behavior coerces the
undefinedto a 0, which leads to an infinite loop where the filesystem repeatedly asks to read/write the same data since it sees no progress. I added a check that writes an error message to the console and sets EIO when undefined is returned so the infinite loop is prevented and the problem is explained.