-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
stdio: make stdout and stderr emit 'close' on destroy #26691
Conversation
if (!this._writableState.emitClose) { | ||
process.nextTick(() => { | ||
this.emit('close'); | ||
}); |
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.
How come the nextTick
is required in this case?
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.
The previous cb() could emitting an error via nextTick. Close should be emitted afterwards.
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.
Are you ok/can this PR land, or would you like to see some different resolution for this?
// SyncWriteStream does not use the stream | ||
// destroy mechanism for some legacy reason. | ||
// TODO(mcollina): remove when | ||
// https://github.com/nodejs/node/pull/26690 lands. |
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.
What exactly are you intending to remove? The dummyDestroy()
function? It’s intentional that stdio streams, SyncWriteStream or not, cannot “really” be closed (so that file descriptors 0, 1, 2 don’t accidentally get closed).
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.
The if check underneath. See the linked PR. Basically we can have a callback or not for this function.
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.
#26690 was merged so this needs to go now?
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.
We can! However that was a semver-major commit and this is not. I would prefer to issue a follow-up PR that will not be backported. This can (and should) be backported.
@nodejs/build can you take a look at https://ci.nodejs.org/job/node-test-commit-linux/26139/nodes=ubuntu1604-64/console? there seems a problem with that machine, if failed a couple of times. |
I've updated, cleaned and rebooted that ubuntu machine, will see if that helps |
A root-owned directory was left around after some troubleshooting (generating a core file for another issue), and Resume Build CI: https://ci.nodejs.org/job/node-test-pull-request/21615/ ✅ |
I will look to land this next Monday if there are no further objections. I'd also open a new PR to remove that if check at the same time. |
Landed in bdea725 |
Fix: #26550 PR-URL: #26691 Fixes: https://github.com/false Fixes: #26550 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net>
nodejs#26691 introduced an if to protect against SyncWriteStream not using the default .destroy() mechanism. This change removes that as SyncWriteStream now use standard .destroy(). See: nodejs#26691
Commit landed with messed up metadata, I guess it's too late to fix it. |
Ouch, I didn't notice. I relied too blindly on git node land. |
We should probably add some stricter checks in https://github.com/nodejs/core-validate-commit for these cases |
Fix: nodejs#26550 PR-URL: nodejs#26691 Fixes: https://github.com/false Fixes: nodejs#26550 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net>
Fix: #26550 PR-URL: #26691 Fixes: https://github.com/false Fixes: #26550 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net>
#26691 introduced an if to protect against SyncWriteStream not using the default .destroy() mechanism. This change removes that as SyncWriteStream now use standard .destroy(). See: #26691 PR-URL: #26902 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net>
|
#26691 introduced an if to protect against SyncWriteStream not using the default .destroy() mechanism. This change removes that as SyncWriteStream now use standard .destroy(). See: #26691 PR-URL: #26902 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net>
@mcollina should this still land on v10.x? |
Yes please |
Fix: #26550 PR-URL: #26691 Fixes: https://github.com/false Fixes: #26550 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net>
Fix: #26550 PR-URL: #26691 Fixes: https://github.com/false Fixes: #26550 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net>
The problem in #26550 was caused by
net.Socket
having setemitClose: false
because it was emitted its own event in_destroy()
, andstdio.js
was overriding_destroy
without emitting'close'
.Fix: #26550
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes