Commit 5fc4e48
doc: add note about AsyncResource for Worker pooling
When implementing a pool for Worker threads, the correlation between
posting tasks and getting their results may get lost, depending on
the implementation.
The `AsyncResource` API is the primary way to solve that issue,
so link it from the recommendation in the worker docs.
(This was brought up at the collaborator summit in Berlin.)
PR-URL: #28023
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>1 parent b491eab commit 5fc4e48
1 file changed
Lines changed: 5 additions & 0 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
@@ -49,6 +49,10 @@ The above example spawns a Worker thread for each `parse()` call. In actual | |||
| 49 | 49 | practice, use a pool of Workers instead for these kinds of tasks. Otherwise, the | |
| 50 | 50 | overhead of creating Workers would likely exceed their benefit. | |
| 51 | 51 | ||
| 52 | + When implementing a worker pool, use the [`AsyncResource`][] API to inform | ||
| 53 | + diagnostic tools (e.g. in order to provide asynchronous stack traces) about the | ||
| 54 | + correlation between tasks and their outcomes. | ||
| 55 | + | ||
| 52 | 56 | ## worker.isMainThread | |
| 53 | 57 | <!-- YAML | |
| 54 | 58 | added: v10.5.0 | |
@@ -653,6 +657,7 @@ active handle in the event system. If the worker is already `unref()`ed calling | |||
| 653 | 657 | `unref()` again will have no effect. | |
| 654 | 658 | ||
| 655 | 659 | [`'close'` event]: #worker_threads_event_close | |
| 660 | + [`AsyncResource`]: async_hooks.html#async_hooks_class_asyncresource | ||
| 656 | 661 | [`Buffer`]: buffer.html | |
| 657 | 662 | [`EventEmitter`]: events.html | |
| 658 | 663 | [`EventTarget`]: https://developer.mozilla.org/en-US/docs/Web/API/EventTarget | |
0 commit comments