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

Tracking Issue: process.binding('async_wrap') #37575

Closed
jasnell opened this issue Mar 2, 2021 · 7 comments
Closed

Tracking Issue: process.binding('async_wrap') #37575

jasnell opened this issue Mar 2, 2021 · 7 comments

Comments

@jasnell
Copy link
Member

jasnell commented Mar 2, 2021

@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 with process.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 the Providers are marginally useful for user code and can be re-exported via the async_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 with Providers re-exported via require('async_hooks').

> process.binding('async_wrap')
BaseObject {
  setupHooks: [Function: setupHooks],
  setCallbackTrampoline: [Function: setCallbackTrampoline],
  pushAsyncContext: [Function: pushAsyncContext],
  popAsyncContext: [Function: popAsyncContext],
  executionAsyncResource: [Function: executionAsyncResource],
  clearAsyncIdStack: [Function: clearAsyncIdStack],
  queueDestroyAsyncId: [Function: queueDestroyAsyncId],
  enablePromiseHook: [Function: enablePromiseHook],
  disablePromiseHook: [Function: disablePromiseHook],
  registerDestroyHook: [Function: registerDestroyHook],
  async_hook_fields: Uint32Array(9) [
    1, 1, 1, 1, 0,
    4, 2, 1, 0
  ],
  async_id_fields: Float64Array(4) [ 5, 0, 126, -1 ],
  execution_async_resources: [ TTY { reading: true, [Symbol(owner_symbol)]: [ReadStream] } ],
  async_ids_stack: Float64Array(32) [
    0, 0, 5, 0, 124, 5, 0, 0, 0,
    0, 0, 0, 0,   0, 0, 0, 0, 0,
    0, 0, 0, 0,   0, 0, 0, 0, 0,
    0, 0, 0, 0,   0
  ],
  constants: {
    kInit: 0,
    kBefore: 1,
    kAfter: 2,
    kDestroy: 3,
    kPromiseResolve: 4,
    kTotals: 5,
    kCheck: 6,
    kExecutionAsyncId: 0,
    kTriggerAsyncId: 1,
    kAsyncIdCounter: 2,
    kDefaultTriggerAsyncId: 3,
    kUsesExecutionAsyncResource: 8,
    kStackLength: 7
  },
  Providers: {
    NONE: 0,
    DIRHANDLE: 1,
    DNSCHANNEL: 2,
    ELDHISTOGRAM: 3,
    FILEHANDLE: 4,
    FILEHANDLECLOSEREQ: 5,
    FIXEDSIZEBLOBCOPY: 6,
    FSEVENTWRAP: 7,
    FSREQCALLBACK: 8,
    FSREQPROMISE: 9,
    GETADDRINFOREQWRAP: 10,
    GETNAMEINFOREQWRAP: 11,
    HEAPSNAPSHOT: 12,
    HTTP2SESSION: 13,
    HTTP2STREAM: 14,
    HTTP2PING: 15,
    HTTP2SETTINGS: 16,
    HTTPINCOMINGMESSAGE: 17,
    HTTPCLIENTREQUEST: 18,
    JSSTREAM: 19,
    JSUDPWRAP: 20,
    MESSAGEPORT: 21,
    PIPECONNECTWRAP: 22,
    PIPESERVERWRAP: 23,
    PIPEWRAP: 24,
    PROCESSWRAP: 25,
    PROMISE: 26,
    QUERYWRAP: 27,
    SHUTDOWNWRAP: 28,
    SIGNALWRAP: 29,
    STATWATCHER: 30,
    STREAMPIPE: 31,
    TCPCONNECTWRAP: 32,
    TCPSERVERWRAP: 33,
    TCPWRAP: 34,
    TTYWRAP: 35,
    UDPSENDWRAP: 36,
    UDPWRAP: 37,
    SIGINTWATCHDOG: 38,
    WORKER: 39,
    WORKERHEAPSNAPSHOT: 40,
    WRITEWRAP: 41,
    ZLIB: 42,
    CHECKPRIMEREQUEST: 43,
    PBKDF2REQUEST: 44,
    KEYPAIRGENREQUEST: 45,
    KEYGENREQUEST: 46,
    KEYEXPORTREQUEST: 47,
    CIPHERREQUEST: 48,
    DERIVEBITSREQUEST: 49,
    HASHREQUEST: 50,
    RANDOMBYTESREQUEST: 51,
    RANDOMPRIMEREQUEST: 52,
    SCRYPTREQUEST: 53,
    SIGNREQUEST: 54,
    TLSWRAP: 55,
    VERIFYREQUEST: 56,
    INSPECTORJSBINDING: 57
  }
}
@addaleax
Copy link
Member

addaleax commented Mar 2, 2021

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.

@jasnell
Copy link
Member Author

jasnell commented Mar 2, 2021

The names themselves I can see being useful. The identifiers not so much. Perhaps instead we can export an array of the provider names?

@addaleax
Copy link
Member

addaleax commented Mar 2, 2021

But the names are also only internal – so what is a diagnostic utility going to do with them?

@jasnell
Copy link
Member Author

jasnell commented Mar 2, 2021

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,

@addaleax
Copy link
Member

addaleax commented Mar 2, 2021

they are exposed via the async_hooks init, and via trace events.

I know that, but why the list then?

It would also be useful in at least attempting not to duplicate when creating your own resources,

And if we just namespaced the Node.js ones…?

(Also, /cc @nodejs/async_hooks)

@jasnell
Copy link
Member Author

jasnell commented Mar 2, 2021

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.

@jasnell
Copy link
Member Author

jasnell commented Mar 2, 2021

For now, I'll drop the export in the PR

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

Successfully merging a pull request may close this issue.

2 participants