-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
Tracking Issue: process.binding('async_wrap') #37575
Comments
I guess the question is, how would these internal identifiers be used? I would lean towards runtime-deprecating this altogether – I think we have that leeway especially considering that async_hooks are still experimental. |
The names themselves I can see being useful. The identifiers not so much. Perhaps instead we can export an array of the provider names? |
But the names are also only internal – so what is a diagnostic utility going to do with them? |
they are exposed via the async_hooks init, and via trace events. It would also be useful in at least attempting not to duplicate when creating your own resources, |
I know that, but why the list then?
And if we just namespaced the Node.js ones…? (Also, /cc @nodejs/async_hooks) |
namespacing them would work also. That would be a major change in itself tho for anyone currently using async_hooks to keep track of the existing names. |
For now, I'll drop the export in the PR |
@addaleax ... given your comments here, I want to start going through the various exported
process.binding()
bits one by one to see what can be done... let's start withprocess.binding('async_wrap')
.Here's what is currently exported:
I would argue that none of the functions here are safe to export to user code. There are some hits on github search for
process.binding('async_wrap')
that are.... interesting and highly questionable approaches.The shared state typed arrays are also definitely not safe to export to user code here.
The
constants
are harmless but useless to user code. At most, I think theProviders
are marginally useful for user code and can be re-exported via theasync_hooks
module.Given that, I would suggest that
process.binding('async_wrap')
is one that we should runtime deprecate access to as a whole, but withProviders
re-exported viarequire('async_hooks')
.The text was updated successfully, but these errors were encountered: