Uh oh!
There was an error while loading. Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork 34.3k
stream: make .destroy() interact better with write queue#24062
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
Uh oh!
There was an error while loading. Please reload this page.
Conversation
addaleax commented Nov 3, 2018 • edited
Loading Uh oh!
There was an error while loading. Please reload this page.
edited
Uh oh!
There was an error while loading. Please reload this page.
Make sure that it is safe to call the callback for `_write()` even in the presence of `.destroy()` calls during that write. In particular, letting the write queue continue processing would previously have thrown an exception, because processing writes after calling `.destroy()` is forbidden. One test had to be modified to account for the fact that callbacks for writes will now always be called, even when the stream is destroyed during the process.
nodejs-github-bot commented Nov 3, 2018
addaleax commented Nov 3, 2018
addaleax commented Nov 3, 2018 • edited
Loading Uh oh!
There was an error while loading. Please reload this page.
edited
Uh oh!
There was an error while loading. Please reload this page.
Huh, apparently the test change was only necessary for an earlier version of this patch… interesting. I’m not sure I like this behavior, but on the other hand it means that this is more likely to pass as semver-patch? New CI: https://ci.nodejs.org/job/node-test-pull-request/18319/ (:heavy_check_mark:) |
addaleax commented Nov 3, 2018
CITGM doesn’t seem to display any results at all…? /cc @nodejs/build-infra |
mcollina left a comment
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 with green CI
addaleax commented Nov 5, 2018 • edited
Loading Uh oh!
There was an error while loading. Please reload this page.
edited
Uh oh!
There was an error while loading. Please reload this page.
addaleax commented Nov 7, 2018
Any other thoughts/reviewers? |
addaleax commented Nov 10, 2018
Landed in d3f02d0 |
Make sure that it is safe to call the callback for `_write()` even in the presence of `.destroy()` calls during that write. In particular, letting the write queue continue processing would previously have thrown an exception, because processing writes after calling `.destroy()` is forbidden. One test had to be modified to account for the fact that callbacks for writes will now always be called, even when the stream is destroyed during the process. PR-URL: nodejs#24062 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]>
Make sure that it is safe to call the callback for `_write()` even in the presence of `.destroy()` calls during that write. In particular, letting the write queue continue processing would previously have thrown an exception, because processing writes after calling `.destroy()` is forbidden. One test had to be modified to account for the fact that callbacks for writes will now always be called, even when the stream is destroyed during the process. PR-URL: #24062 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]>
Make sure that it is safe to call the callback for `_write()` even in the presence of `.destroy()` calls during that write. In particular, letting the write queue continue processing would previously have thrown an exception, because processing writes after calling `.destroy()` is forbidden. One test had to be modified to account for the fact that callbacks for writes will now always be called, even when the stream is destroyed during the process. PR-URL: nodejs#24062 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]>
Make sure that it is safe to call the callback for `_write()` even in the presence of `.destroy()` calls during that write. In particular, letting the write queue continue processing would previously have thrown an exception, because processing writes after calling `.destroy()` is forbidden. One test had to be modified to account for the fact that callbacks for writes will now always be called, even when the stream is destroyed during the process. PR-URL: #24062 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]>
Make sure that it is safe to call the callback for `_write()` even in the presence of `.destroy()` calls during that write. In particular, letting the write queue continue processing would previously have thrown an exception, because processing writes after calling `.destroy()` is forbidden. One test had to be modified to account for the fact that callbacks for writes will now always be called, even when the stream is destroyed during the process. PR-URL: #24062 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]>
@nodejs/streams @mcollina@mafintosh I’m mostly looking for feedback on the idea here rather than the implementation, i.e., does this make sense, is this the right behaviour, etc.?
Also, does the test modification here mean that we might have to consider this a breaking change rather than a bugfix?Make sure that it is safe to call the callback for
_write()even in the presence of
.destroy()calls during that write.In particular, letting the write queue continue processing would
previously have thrown an exception, because processing writes
after calling
.destroy()is forbidden.One test had to be modified to account for the fact that callbacksfor writes will now always be called, even when the stream
is destroyed during the process.
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passes