-
-
Notifications
You must be signed in to change notification settings - Fork 33.5k
child_process: add hasRef to ChildProcess #42731
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
Conversation
Refs: nodejs#42091 The issue above reported a specific use case about `hasRef()`. After reading the issue, I started thinking users may naturally expect `hasRef` method if `ref()` and `unref()` exist on an object they use. As of now, however, `hasRef()` exists on `Timer` only. This commit suggests adding `hasRef` method to `ChildProcess` first. There are more similar cases. (fs.FSWatcher, fs.StatWatcher, net.Socket, and so on)
24eff20 to
9a5f852
Compare
This removes assertions where the child could be {un}referred.
9a5f852 to
3cd3796
Compare
lib/internal/child_process.js
Outdated
|
|
||
|
|
||
| ChildProcess.prototype.hasRef = function() { | ||
| return this._handle ? this._handle.hasRef() : false; |
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.
| return this._handle ? this._handle.hasRef() : false; | |
| return !!this._handle?.hasRef() |
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.
applied the suggestion.
|
cc @nodejs/child_process |
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.
Actually, I don't think we should expose hasRef() from the ChildProcess JS object because jest uses async_hooks to collect open handles and the init() callback gets called with resource set to the underlying PROCESSWRAP handle object (this._handle) which already contains the hasRef() method.
To be able to correctly report open ChildProcess handles correctly, jest needs to change https://github.com/facebook/jest/blob/defbc0535a46119d4682f97bf8a13b5562c1445b/packages/jest-core/src/collectHandles.ts#L96:
- to also include
PROCESSWRAPOR - just accept all
types of async resources
The reason why Timer objects have the hasRef() method is that it isn't backed up by a C++ HandleWrap instance like the other cases. Essentially, the resource variable that the async_hooks init() callback gets called with is the same as the return value of setTimeout().
In the issue above, although SimenB had no opinion requiring |
Refs: #42091
The issue above reported a specific use case about
hasRef().After reading the issue, I started thinking users may naturally expect
hasRefmethod ifref()andunref()exist on an object they use.As of now, however,
hasRef()exists onTimeronly.This commit suggests adding
hasRefmethod toChildProcessfirst.There are more similar cases. (fs.FSWatcher, fs.StatWatcher, net.Socket,
and so on)