Skip to content
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

ability to abort a pipeline from openReadStream #26

Closed
thejoshwolfe opened this issue Dec 31, 2015 · 3 comments
Closed

ability to abort a pipeline from openReadStream #26

thejoshwolfe opened this issue Dec 31, 2015 · 3 comments

Comments

@thejoshwolfe
Copy link
Owner

The unpipe branch currently has a test failure due to trying to walk away from an 8GB read stream after reading 0x100 bytes. The pipe is left open, and yazul never emits the close event.

In general, we should have the ability to abort a read stream partway through. According to my research, we need to provide this feature rather than relying on some existing Node solution that works for all generic streams and pipes.

Credit to @timotm for finding this limitation 8 months ago in #13.

@thejoshwolfe
Copy link
Owner Author

The difficulty in supporting this issue is that there really isn't any generic way to shutdown a readable stream before reaching the end event. yauzl uses fd-slicer, which implements an autoClose feature. If we're going to have the ability to abort a readable stream without wrecking the whole fd, we're going to need fd-slicer's cooperation.

Furthermore, fd-slicer is just one backend supported by yauzl. the fromRandomAccessReader method accepts any user-defined backend as specified by the readme. We may also need the user's own backend to support mid-stream abortion if this feature is going to work. (This would not be a breaking API change, because this feature can be optionally implemented by and used by the same user.)

And just to make things a little more complicated, yauzl pipes the readable stream it gets from fd-slicer (or the user-defined backend) through at least a couple filter streams before giving the user the endpoint stream. These filter streams do things such as count bytes for security purposes and inflate compressed data.

@thejoshwolfe
Copy link
Owner Author

See also #27.

@KernelDeimos
Copy link

@thejoshwolfe Has .destroy() on Readable introduced in node.js 8 changed any of this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants