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

Migrating from object.ref()/object.unref() to process.ref()/process.unref() #53266

Open
jasnell opened this issue Jun 2, 2024 · 5 comments
Open

Comments

@jasnell
Copy link
Member

jasnell commented Jun 2, 2024

Node.js has long had a pattern of attaching a ref() and unref() method to various i/o objects that are bound to the event loop. Calling thing.unref() makes it so the thing does not keep the event loop alive.

For instance,

const i = setInterval(() => {}, 1000);
i.unref();

While this has worked effectively for Node.js specific APIs, it's rather cumbersome with web platform standard APIs. I'd like to propose a change: Introduce new process.unref(thing) and process.ref(thing) API that would accept multiple different kinds of ref'able types.

const i = setInterval(() => {}, 1000);
process.unref(i);
// etc

A number of API objects that currently have .ref()/.unref() methods:

  • dgram.Socket
  • net.Socket
  • net.Server
  • child_process.ChildProcess
  • child_process.Control
  • StatWatcher
  • FSWatcher
  • MessagePort
  • Timeout
  • Interval
  • Worker
  • Http2Session
  • BroadcastChannel

The idea would be to mark the existing object-specific ref() and unref() methods as legacy and depend on the process.ref()/process.unref() as the supported mechanism moving forward.

/cc @mcollina

@benjamingr
Copy link
Member

+1 this makes sense to do from the outside

@mcollina
Copy link
Member

mcollina commented Jun 4, 2024

+1 for me.

However we are never going to be able to remove the previous methods either (unfortunately), as they will break everybody.

@anonrig
Copy link
Member

anonrig commented Jun 6, 2024

+1

@jasnell
Copy link
Member Author

jasnell commented Jun 12, 2024

Ok, given the thumbs up on it, I'll start working this up

@jasnell
Copy link
Member Author

jasnell commented Jun 12, 2024

@mcollina :

However we are never going to be able to remove the previous methods either (unfortunately), as they will break everybody.

Yeah, I know. My plan would be to keep those existing methods in place but change them to use the new mechanism under the covers. The public APIs would then be marked as legacy with a note to use the new process.(un)ref API.

jasnell added a commit to jasnell/node that referenced this issue Dec 29, 2024
The `process.ref(...)` and `process.unref(...)` methods are intended
to replace the use of `ref()` and `unref()` methods defined directly
on individual API objects. The existing `ref()` and `unref()` methods
will be marked as legacy and won't be removed but new APIs should use
`process.ref()` and `process.unref()` instead.

Refs: nodejs#53266
jasnell added a commit that referenced this issue Dec 31, 2024
The `process.ref(...)` and `process.unref(...)` methods are intended
to replace the use of `ref()` and `unref()` methods defined directly
on individual API objects. The existing `ref()` and `unref()` methods
will be marked as legacy and won't be removed but new APIs should use
`process.ref()` and `process.unref()` instead.

Refs: #53266
PR-URL: #56400
Reviewed-By: Matteo Collina <[email protected]>
Reviewed-By: Yagiz Nizipli <[email protected]>
Reviewed-By: Chemi Atlow <[email protected]>
aduh95 pushed a commit that referenced this issue Jan 2, 2025
The `process.ref(...)` and `process.unref(...)` methods are intended
to replace the use of `ref()` and `unref()` methods defined directly
on individual API objects. The existing `ref()` and `unref()` methods
will be marked as legacy and won't be removed but new APIs should use
`process.ref()` and `process.unref()` instead.

Refs: #53266
PR-URL: #56400
Reviewed-By: Matteo Collina <[email protected]>
Reviewed-By: Yagiz Nizipli <[email protected]>
Reviewed-By: Chemi Atlow <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants