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

stdio: call _undestroy() inside _destroy for stdout and stderr #39685

Closed
wants to merge 1 commit into from

Conversation

mcollina
Copy link
Member

@mcollina mcollina commented Aug 6, 2021

Fixes: #39447

@nodejs-github-bot nodejs-github-bot added the needs-ci PRs that need a full CI run. label Aug 6, 2021
@mcollina mcollina marked this pull request as draft August 6, 2021 11:07
@addaleax
Copy link
Member

addaleax commented Aug 6, 2021

Yeah, I think this is preferable 👍 Might be good to have a few tests though

@mcollina
Copy link
Member Author

mcollina commented Aug 6, 2021

yep, I plan to add them as soon as we have cleared the approach.

@mcollina
Copy link
Member Author

mcollina commented Aug 6, 2021

would this be semver-patch or semver-major?

@addaleax
Copy link
Member

addaleax commented Aug 6, 2021

I guess that depends on whether we think people intentionally close stdout/stderr to avoid output – I don’t think it’s a big concern, and I’d say semver-patch is fine, but I also fully understand if we want to be a bit more careful.

@mcollina mcollina added the baking-for-lts PRs that need to wait before landing in a LTS release. label Aug 6, 2021
@mcollina mcollina marked this pull request as ready for review August 6, 2021 13:20
@mcollina
Copy link
Member Author

mcollina commented Aug 6, 2021

Test added

@nodejs-github-bot
Copy link
Collaborator

if (process.argv[2] === 'child') {
process.stdout.destroy()
console.log('out')
console.error('err')
Copy link
Member

Choose a reason for hiding this comment

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

We should also test that

  • This applies when process.stderr.destroy() is also called (otherwise the console.error test is not meaningful)
  • Explicitly using process.stdout.write() works
  • Explicitly using process.stderr.write() works
  • Writing after a short timeout works (since destroy() can, generally speaking, be asynchronous)

test/parallel/test-stdio-undestroy.js Outdated Show resolved Hide resolved
@jasnell
Copy link
Member

jasnell commented Aug 6, 2021

Not blocking but the whole _undestroy() as a publicly accessible method just still feels icky to me. We really ought to work towards deprecating the public _undestroy() and hide it behind a hidden symbol or find an alternative approach at some point. Even just having something like a destroyable: false option on the constructor might be sufficient that, when set, causes calling destroy() to be a non-op on the instance.

@ktfth
Copy link

ktfth commented Aug 6, 2021

You know why on coverage-linux go out of memory? And this process need docs? I'm following this changes to help more on future contributions using this example

@mcollina
Copy link
Member Author

mcollina commented Aug 9, 2021

Not blocking but the whole _undestroy() as a publicly accessible method just still feels icky to me. We really ought to work towards deprecating the public _undestroy() and hide it behind a hidden symbol or find an alternative approach at some point. Even just having something like a destroyable: false option on the constructor might be sufficient that, when set, causes calling destroy() to be a non-op on the instance.

_undestroy() was added solely at Node.js core benefit (prior to when we add Symbols). This was needed because we support reattaching the socket to our net connections. I'm not sure we can easily do without it.

@mcollina
Copy link
Member Author

mcollina commented Aug 9, 2021

@addaleax I have filled in the missing tests.

@nodejs-github-bot
Copy link
Collaborator

Copy link
Member

@addaleax addaleax left a comment

Choose a reason for hiding this comment

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

LGTM once the linter is happy

@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot
Copy link
Collaborator

This change makes `process.stdout` and `process.stderr` to be
automatically undestroyed when ended/destrouyed, therefore making
it always possible to write/console.log to stdout.

Fixes: nodejs#39447
@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot
Copy link
Collaborator

Copy link
Member

@joyeecheung joyeecheung left a comment

Choose a reason for hiding this comment

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

Not knowing enough about streams, what it does to the bootstrap and the tests LGTM.

I have a question though, would it be in conflict with 7b2ca4c (part of the WIP #38905) which tries to run the original destroy for the streams during beforeExit because when building the snapshots the fds should be closed? (I am guessing not, because only one of the dummyDestroy and the original destroy would be called?)

@mcollina
Copy link
Member Author

@joyeecheung in #38905 you might need to call _undestroy() on the streams if the instance is persisted in the snapshots.

@nodejs-github-bot
Copy link
Collaborator

mcollina added a commit that referenced this pull request Aug 11, 2021
This change makes `process.stdout` and `process.stderr` to be
automatically undestroyed when ended/destrouyed, therefore making
it always possible to write/console.log to stdout.

Fixes: #39447

PR-URL: #39685
Reviewed-By: Robert Nagy <ronagy@icloud.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
@mcollina
Copy link
Member Author

Landed in 33f9b7f

@mcollina mcollina closed this Aug 11, 2021
danielleadams pushed a commit that referenced this pull request Aug 16, 2021
This change makes `process.stdout` and `process.stderr` to be
automatically undestroyed when ended/destrouyed, therefore making
it always possible to write/console.log to stdout.

Fixes: #39447

PR-URL: #39685
Reviewed-By: Robert Nagy <ronagy@icloud.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
@targos targos removed the baking-for-lts PRs that need to wait before landing in a LTS release. label Sep 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-ci PRs that need a full CI run.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

stream.pipeline does not invoke callback when error happens
9 participants