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

doc: add comments about Readable unpipe on Writable error event in stream.md #18080

Closed
wants to merge 1 commit into from
Closed

doc: add comments about Readable unpipe on Writable error event in stream.md #18080

wants to merge 1 commit into from

Conversation

GeorgeSapkin
Copy link
Contributor

Documenting Readable unpiping behavior according to: https://github.com/nodejs/node/blob/v8.x/lib/_stream_readable.js#L656-L664

Checklist
Affected core subsystem(s)

doc

@nodejs-github-bot nodejs-github-bot added doc Issues and PRs related to the documentations. stream Issues and PRs related to the stream subsystem. labels Jan 10, 2018
@addaleax
Copy link
Member

Hi, thanks for the PR! You edited the section for stream implementors that tells them how to report errors; I think this would be better kept in the section about .pipe() itself? Also, it might not be clear from the current wording on which of the two streams emitting the error event stops piping.

@GeorgeSapkin
Copy link
Contributor Author

Do you think it should be in Readable.pipe() section? It seems to me it affects the Writable stream implementers more since right now it is not clear what happens when Writable emits errors. Maybe it should be in both or there should some kind of a reference between the sections?

I've improved the wording to make it clearer which stream emits an error.

@@ -1508,6 +1508,9 @@ the callback and passing the error as the first argument. This will cause an
on how the stream is being used. Using the callback ensures consistent and
predictable handling of errors.

*Note*: If a Readable stream pipes into a Writable stream when Writable emits an
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Consider removing *Note*: and letting the sentence stand on its own?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems like something that requires special attention when implementing error handling in Writable streams and STYLE_GUIDE.md recommends to mark such things with a *Note*:.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That should probably be updated as well. We try to minimize those because they became to frequent and therefore lost there meaning.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've removed the *Note*.

@@ -1508,6 +1508,9 @@ the callback and passing the error as the first argument. This will cause an
on how the stream is being used. Using the callback ensures consistent and
predictable handling of errors.

*Note*: If a Readable stream pipes into a Writable stream when Writable emits an
error, Readable stream will be unpiped.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: add the before Readable stream.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@BridgeAR
Copy link
Member

BridgeAR commented Feb 1, 2018

@GeorgeSapkin GeorgeSapkin changed the title doc: add Note about Readable unpipe on Writable error event in stream.md doc: add a comment about Readable unpipe on Writable error event in stream.md Feb 5, 2018
@GeorgeSapkin
Copy link
Contributor Author

@BridgeAR why would this be in the Writable pipe event's section (judging from your link)? Did you mean error or unpipe?

@BridgeAR
Copy link
Member

BridgeAR commented Feb 5, 2018

@GeorgeSapkin yes unpipe is probably the correct one in this case. But it should be reworded in that case.

Something like e.g. might fit?

This will also be called in case this Writable stream emits an error.

@mcollina PTAL

Copy link
Member

@mcollina mcollina left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@mcollina
Copy link
Member

mcollina commented Feb 6, 2018

I think we should really add the sentence in 2-3 places. It's one of the most forgotten (and bad) features of streams.

I would also note that calling unpipe() means the stream does not get closed.

@GeorgeSapkin
Copy link
Contributor Author

@BridgeAR @mcollina I've added another remark in the Writable unpipe event's sections.

@GeorgeSapkin GeorgeSapkin changed the title doc: add a comment about Readable unpipe on Writable error event in stream.md doc: add comments about Readable unpipe on Writable error event in stream.md Feb 8, 2018
@mcollina
Copy link
Member

mcollina commented Feb 8, 2018

Can you add a sentence about the fact that calling unpipe() means the stream does not get closed.

@BridgeAR
Copy link
Member

Ping @GeorgeSapkin

@GeorgeSapkin
Copy link
Contributor Author

@mcollina I'm not sure I understand where the note about streams not being closed on unpipe needs to be added and why that (i.e. automatic closing of a stream) would be assumed to be the case to begin with.

@mcollina
Copy link
Member

@GeorgeSapkin the main reason is that a stream is typically holding on to some native resources. A file descriptor, or some other native data. If an error happen and the destination stream is unpiped, the underlining native resource is not freed, and will trigger a memory (or file descriptor) leak.

@BridgeAR
Copy link
Member

BridgeAR commented Mar 2, 2018

I would say we can land this as is (it already improves the current situation) and we have a follow up PR that addresses your comment @mcollina ?

@mcollina
Copy link
Member

mcollina commented Mar 2, 2018

👍

@mcollina
Copy link
Member

mcollina commented Mar 2, 2018

@mcollina
Copy link
Member

mcollina commented Mar 2, 2018

Landed in 1d19fd3

@mcollina mcollina closed this Mar 2, 2018
mcollina pushed a commit that referenced this pull request Mar 2, 2018
PR-URL: #18080
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
addaleax pushed a commit to addaleax/node that referenced this pull request Mar 5, 2018
PR-URL: nodejs#18080
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
@MylesBorins MylesBorins mentioned this pull request Mar 6, 2018
@GeorgeSapkin GeorgeSapkin deleted the stream-unpipe-doc branch March 29, 2018 10:57
MayaLekova pushed a commit to MayaLekova/node that referenced this pull request May 8, 2018
PR-URL: nodejs#18080
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
jasnell pushed a commit to jasnell/node that referenced this pull request Aug 17, 2018
PR-URL: nodejs#18080
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
MylesBorins pushed a commit that referenced this pull request Sep 6, 2018
Backport-PR-URL: #22380
PR-URL: #18080
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
@MylesBorins MylesBorins mentioned this pull request Sep 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
doc Issues and PRs related to the documentations. stream Issues and PRs related to the stream subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants