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

child_process: create proper public API for channel #30165

Closed

Conversation

addaleax
Copy link
Member

Instead of exposing the C++ bindings object as subprocess.channel
or process.channel, provide the “control” object that was
previously used internally as the public-facing variant of it.

This should be better than returning the raw pipe object, and
matches the original intention (when the channel property was
first added) of providing a proper way to .ref() or .unref()
the channel.

Refs: #9322
Refs: #9313

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines

@addaleax addaleax added child_process Issues and PRs related to the child_process subsystem. semver-major PRs that contain breaking changes and should be released in the next major version. labels Oct 29, 2019
@nodejs-github-bot nodejs-github-bot added the process Issues and PRs related to the process subsystem. label Oct 29, 2019
@addaleax addaleax added the review wanted PRs that need reviews. label Nov 1, 2019
@nodejs-github-bot
Copy link
Collaborator

@addaleax
Copy link
Member Author

addaleax commented Nov 1, 2019

CITGM: https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/2081/

@nodejs/child_process

doc/api/child_process.md Outdated Show resolved Hide resolved
doc/api/child_process.md Outdated Show resolved Hide resolved
@addaleax
Copy link
Member Author

addaleax commented Nov 2, 2019

@vsemozhetbyt If it makes things easier for you, you can feel free to push to my branches directly – your suggestions are always helpful and I trust you to know how the docs should ideally look like :)

@vsemozhetbyt
Copy link
Contributor

@addaleax Thank you) Personally, I am not so sure about my nitpicking myself, and recently I usually review in occasions not so convenient for git operations. But I am grateful for your lingering encouragement)

// in progress. Once the user has explicitly requested a certain state, these
// methods become no-ops in order to not interfere with the user's intentions.
refCounted() {
if (++this.#refs === 1 && !this.#refExplicitlySet) {
Copy link
Member

Choose a reason for hiding this comment

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

Is refExplicitlySet necessary? Are these *Counted methods? It's the user's responsibility to pair ref and unref calls, balancing internal ref/unref calls is our responsibility. I'm not sure I see why they're needed.

Copy link
Member Author

Choose a reason for hiding this comment

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

@bnoordhuis Yeah, I’m not a fan of this either, but without this tests are failing and I wouldn’t know a better solution … the issue isn’t so much that the calls might end up unbalanced, it’s that currently, a process.channel.unref() call for example from userland is expected to unref the channel even if there are event listeners that would otherwise keep it ref()’ed.

@bnoordhuis
Copy link
Member

Oh, and for a bit of meta discussion: I added the control object as a fix for a bug, I didn't otherwise put a lot of thought into it.

Since you're thinking of promoting it to public API: do you think it's the best possible interface?

@addaleax
Copy link
Member Author

addaleax commented Nov 5, 2019

Oh, and for a bit of meta discussion: I added the control object as a fix for a bug, I didn't otherwise put a lot of thought into it.

Since you're thinking of promoting it to public API: do you think it's the best possible interface?

I think it’s fine … or, rather, I think having an API of the shape { ref(), unref(), get fd() } seems okay to me for now, and if we ever need something else I don’t think there’s anything in the way of adding that? I just don’t want to have the raw Pipe object exposed here…

@nodejs-github-bot
Copy link
Collaborator

@bnoordhuis
Copy link
Member

bnoordhuis commented Nov 6, 2019

parallel/test-child-process-pipe-dataflow failure on Windows looks related.

edit: although it could also be #25988.

@nodejs-github-bot
Copy link
Collaborator

doc/api/child_process.md Outdated Show resolved Hide resolved
doc/api/process.md Outdated Show resolved Hide resolved
lib/internal/process/stdio.js Outdated Show resolved Hide resolved
@addaleax
Copy link
Member Author

@lundibundi Addressed your comments and rebased, PTAL

@nodejs-github-bot
Copy link
Collaborator

lib/internal/child_process.js Outdated Show resolved Hide resolved
@BridgeAR
Copy link
Member

This needs a rebase.

@BridgeAR
Copy link
Member

BridgeAR commented Jan 2, 2020

Ping @addaleax

Instead of exposing the C++ bindings object as `subprocess.channel`
or `process.channel`, provide the “control” object that was
previously used internally as the public-facing variant of it.

This should be better than returning the raw pipe object, and
matches the original intention (when the `channel` property was
first added) of providing a proper way to `.ref()` or `.unref()`
the channel.

Refs: nodejs#9322
Refs: nodejs#9313
@addaleax addaleax force-pushed the child-process-channel-public branch from b47e13e to ef418e1 Compare January 3, 2020 00:53
@addaleax addaleax added author ready PRs that have at least one approval, no pending requests for changes, and a CI started. and removed review wanted PRs that need reviews. labels Jan 3, 2020
@nodejs-github-bot

This comment has been minimized.

@nodejs-github-bot
Copy link
Collaborator

nodejs-github-bot commented Jan 3, 2020

BridgeAR pushed a commit that referenced this pull request Jan 3, 2020
Instead of exposing the C++ bindings object as `subprocess.channel`
or `process.channel`, provide the “control” object that was
previously used internally as the public-facing variant of it.

This should be better than returning the raw pipe object, and
matches the original intention (when the `channel` property was
first added) of providing a proper way to `.ref()` or `.unref()`
the channel.

PR-URL: #30165
Refs: #9322
Refs: #9313
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Reviewed-By: Denys Otrishko <shishugi@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
@BridgeAR
Copy link
Member

BridgeAR commented Jan 3, 2020

Landed in e65bed1 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
author ready PRs that have at least one approval, no pending requests for changes, and a CI started. child_process Issues and PRs related to the child_process subsystem. process Issues and PRs related to the process subsystem. semver-major PRs that contain breaking changes and should be released in the next major version.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants