|
6 | 6 |
|
7 | 7 | <!-- source_link=lib/async_hooks.js -->
|
8 | 8 |
|
| 9 | +We strongly discourage the use of the `async_hooks` API. |
| 10 | +Other APIs that can cover most of its use cases include: |
| 11 | + |
| 12 | +* [`AsyncLocalStorage`][] tracks async context |
| 13 | +* [`process.getActiveResourcesInfo()`][] tracks active resources |
| 14 | + |
9 | 15 | The `node:async_hooks` module provides an API to track asynchronous resources.
|
10 | 16 | It can be accessed using:
|
11 | 17 |
|
@@ -329,18 +335,14 @@ The `type` is a string identifying the type of resource that caused
|
329 | 335 | `init` to be called. Generally, it will correspond to the name of the
|
330 | 336 | resource's constructor.
|
331 | 337 |
|
332 |
| -Valid values are: |
| 338 | +The `type` of resources created by Node.js itself can change in any Node.js |
| 339 | +release. Valid values include `TLSWRAP`, |
| 340 | +`TCPWRAP`, `TCPSERVERWRAP`, `GETADDRINFOREQWRAP`, `FSREQCALLBACK`, |
| 341 | +`Microtask`, and `Timeout`. Inspect the source code of the Node.js version used |
| 342 | +to get the full list. |
333 | 343 |
|
334 |
| -```text |
335 |
| -FSEVENTWRAP, FSREQCALLBACK, GETADDRINFOREQWRAP, GETNAMEINFOREQWRAP, HTTPINCOMINGMESSAGE, |
336 |
| -HTTPCLIENTREQUEST, JSSTREAM, PIPECONNECTWRAP, PIPEWRAP, PROCESSWRAP, QUERYWRAP, |
337 |
| -SHUTDOWNWRAP, SIGNALWRAP, STATWATCHER, TCPCONNECTWRAP, TCPSERVERWRAP, TCPWRAP, |
338 |
| -TTYWRAP, UDPSENDWRAP, UDPWRAP, WRITEWRAP, ZLIB, SSLCONNECTION, PBKDF2REQUEST, |
339 |
| -RANDOMBYTESREQUEST, TLSWRAP, Microtask, Timeout, Immediate, TickObject |
340 |
| -``` |
341 |
| - |
342 |
| -These values can change in any Node.js release. Furthermore users of [`AsyncResource`][] |
343 |
| -likely provide other values. |
| 344 | +Furthermore users of [`AsyncResource`][] create async resources independent |
| 345 | +of Node.js itself. |
344 | 346 |
|
345 | 347 | There is also the `PROMISE` resource type, which is used to track `Promise`
|
346 | 348 | instances and asynchronous work scheduled by them.
|
@@ -414,19 +416,19 @@ of propagating what resource is responsible for the new resource's existence.
|
414 | 416 | ##### `resource`
|
415 | 417 |
|
416 | 418 | `resource` is an object that represents the actual async resource that has
|
417 |
| -been initialized. This can contain useful information that can vary based on |
418 |
| -the value of `type`. For instance, for the `GETADDRINFOREQWRAP` resource type, |
419 |
| -`resource` provides the host name used when looking up the IP address for the |
420 |
| -host in `net.Server.listen()`. The API for accessing this information is |
421 |
| -not supported, but using the Embedder API, users can provide |
422 |
| -and document their own resource objects. For example, such a resource object |
423 |
| -could contain the SQL query being executed. |
| 419 | +been initialized. The API to access the object may be specified by the |
| 420 | +creator of the resource. Resources created by Node.js itself are internal |
| 421 | +and may change at any time. Therefore no API is specified for these. |
424 | 422 |
|
425 | 423 | In some cases the resource object is reused for performance reasons, it is
|
426 | 424 | thus not safe to use it as a key in a `WeakMap` or add properties to it.
|
427 | 425 |
|
428 | 426 | ##### Asynchronous context example
|
429 | 427 |
|
| 428 | +The context tracking use case is covered by the stable API [`AsyncLocalStorage`][]. |
| 429 | +This example only illustrates async hooks operation but [`AsyncLocalStorage`][] |
| 430 | +fits better to this use case. |
| 431 | + |
430 | 432 | The following is an example with additional information about the calls to
|
431 | 433 | `init` between the `before` and `after` calls, specifically what the
|
432 | 434 | callback to `listen()` will look like. The output formatting is slightly more
|
@@ -568,6 +570,9 @@ made to the `resource` object passed to `init` it is possible that `destroy`
|
568 | 570 | will never be called, causing a memory leak in the application. If the resource
|
569 | 571 | does not depend on garbage collection, then this will not be an issue.
|
570 | 572 |
|
| 573 | +Using the destroy hook results in additional overhead because it enables |
| 574 | +tracking of `Promise` instances via the garbage collector. |
| 575 | + |
571 | 576 | #### `promiseResolve(asyncId)`
|
572 | 577 |
|
573 | 578 | <!-- YAML
|
@@ -873,5 +878,6 @@ The documentation for this class has moved [`AsyncLocalStorage`][].
|
873 | 878 | [`before` callback]: #beforeasyncid
|
874 | 879 | [`destroy` callback]: #destroyasyncid
|
875 | 880 | [`init` callback]: #initasyncid-type-triggerasyncid-resource
|
| 881 | +[`process.getActiveResourcesInfo()`]: process.md#processgetactiveresourcesinfo |
876 | 882 | [`promiseResolve` callback]: #promiseresolveasyncid
|
877 | 883 | [promise execution tracking]: #promise-execution-tracking
|
0 commit comments