process: make getActive{Handles,Requests} official#21102
process: make getActive{Handles,Requests} official#21102gpotter2 wants to merge 1 commit intonodejs:masterfrom gpotter2:process-getactive
Conversation
|
If this is going to be a runtime deprecation, you will still need to have the old functions on |
|
That was already said on the previous thread, I had done it but lost the commit, will search for it. Edit: is there no travis unit test on node ? |
There was a problem hiding this comment.
It’s hard to tell for me where this function is being used … also, we’re kind of shifting our timers implementation to not use any handles anymore, /cc @apapirovski
doc/api/process.md
Outdated
There was a problem hiding this comment.
I would really like to take the opportunity now to move these to the async_hooks module or util module and pull them off the process object.
There was a problem hiding this comment.
Because I'd prefer not to expand the API surface area of process if we can reasonably avoid it.
There was a problem hiding this comment.
It's already there though and people use it. I don't see how it makes more sense to place it on the async_hooks or util modules when the data returned by these functions have to strictly do with what's going on in the process.
async_hooks has to do with hooking into asynchronous events, which is not the same thing as inspecting what is currently happening at any given moment (without hooks).
util is essentially a box full of helper functions that work with whatever input they're given, so that doesn't really fit either.
There was a problem hiding this comment.
Maybe you could discuss that in a future PR? I mean, I'm not qualified to answer about this, but I would agree that it's easier to keep the functions where they are.
On the other hand, they were not documented, and could be moved without any further notice
doc/api/deprecations.md
Outdated
There was a problem hiding this comment.
Nit: unnecessary backtick at the end.
doc/api/deprecations.md
Outdated
There was a problem hiding this comment.
`process.getActiveHandles()` and `process.getActiveRequests()`?
doc/api/deprecations.md
Outdated
There was a problem hiding this comment.
This and the next links seem unused in the doc.
doc/api/deprecations.md
Outdated
There was a problem hiding this comment.
Nit: please wrap long lines at 80 characters to prevent doc linting issues.
There was a problem hiding this comment.
Fixed ! (also fixed it in lib/bootstrap/node.js)
|
Update:
|
|
I don't really get why the linter fails on using ` for strings, as it is used everywhere else in the file :/ |
|
It seems linter allows backticks only for template strings: with variable/expression interpolation or inner line breaks. |
|
However, you can use double quotes to avoid escaping if the string contains single quotes: Line 217 in d528781 |
|
@vaibhav93 Replaced single quotes with double quotes. Edit: squashed the commits |
doc/api/deprecations.md
Outdated
There was a problem hiding this comment.
"are getting" is a bit vague, just say "are."
doc/api/process.md
Outdated
There was a problem hiding this comment.
The documentation should make it clear that the returned handles don't always correspond 1-to-1 with user-created handles (only when the internal handle has a .owner property that points back to the user handle but I'd leave out that bit.)
|
Rebased against master to fix the conflicts |
Make process.getActiveHandles() and make.getActiveRequests() official and deprecate the older process._getActiveHandles() and process._getActiveRequests(). Also add a small documentation
|
Rebased (again) against master to fix conflicts. (wow) |
There was a problem hiding this comment.
IMO these APIs should be rethought a bit before exposure, although exposing something like it officially is pretty much what I'm asking for in #20894 (review) & related comments.
My idea would be more like:
- Make it part of the
async_hooksmodule for consistency. - Rename it to
getActiveResources()and return both handles and requests at the same time. - Make it return a map of
asyncId->resource, so that this can be used to dynamically fetch a resource from an async hook call. - Ensure that all async_hook resources are properly fetch-able in this way.
I agree. But be aware that this is a big task, as many async_hooks resource can have uninitialized properties that causes segmentation fault when using edit: Also, if this is for debugging I would suggest we don't add the extra complexity. As it is straight to implement with The resource objects are very internal and undocumented, I'm not a huge fan of exposing them more than they already are if it can be avoided. This is something I would like to fix in |
We've never had such an issue from
It is not for debugging. In my case it is for live (potentially production) resource inspection. Overhead must be minimal.
It's actually very little as most of the complexity already is present in |
|
Feel free to close this PR for #21453 anytime |
|
@gpotter2 Thanks for bringing this up. :) Feel free to add anything you have (use cases, api requirements) in that PR! |
Rebased version of #18844
[Original message]
process._getActiveHandles() and process._getActiveRequests() have been around for a long time, and are utilized to a large enough degree that it makes sense to make them official
APIs.
Fixes: #1128
Checklist :
Affected core subsystem(s)