| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
@Qard I know the SES group doesn't want .domain to be attached to Promises in VMs due to concerns about using it to crawl the object graph to escape some sandboxing. |
Sorry, something went wrong.
|
Yep, that was my finding when I looked up the history of that test file. Not yet sure why that property has returned. I think it'll take a bit of code spelunking to figure out how it's actually suppose to be preventing that currently. |
Sorry, something went wrong.
PR-URL: #39135 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
PR-URL: #39135 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
PR-URL: #39135 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
Promise handling is special-cased for domains and trace_events. Domains must not add the `domain` property to promises in other contexts, and trace_events must be emitted from JavaScript as promises no longer have an AsyncWrap type attached to them. PR-URL: #39135 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
PR-URL: nodejs#39135 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
PR-URL: nodejs#39135 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
PR-URL: nodejs#39135 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
Promise handling is special-cased for domains and trace_events. Domains must not add the `domain` property to promises in other contexts, and trace_events must be emitted from JavaScript as promises no longer have an AsyncWrap type attached to them. PR-URL: nodejs#39135 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
Promise handling is special-cased for domains and trace_events. Domains must not add the `domain` property to promises in other contexts, and trace_events must be emitted from JavaScript as promises no longer have an AsyncWrap type attached to them. PR-URL: #39135 Backport-PR-URL: #39742 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
|
FYI I believe this PR causes issues with SES users and debuggers. See #42229 I'm not sure why, but before this change, attaching a debugger with async stack support didn't cause promise objects to be modified by async_hooks (while still allowing async stack traces to work in the debugger). After this change, promise objects are expanded with the async hooks symbols, which fails if the promise object is frozen. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
I've changed async_hooks use with a destroy hook to use the context-based PromiseHook now and trigger the destroy using the same registerDestroyHook logic that AsyncResource uses. This greatly simplifies the code for async_hooks and the AsyncWrap class.
I've deleted test/addons/async-hooks-promise/* as it's no longer a relevant test with PromiseWrap no longer being a thing.
I also uncovered a tiny inconsistency in that starting the context-based PromiseHook after the init of a promise and before attaching a promise.then(...) to it would result in the child promise having a lower async id than the parent promise due to order of operations in trackPromise(...). That has been fixed here. I can pull it out to a separate fix PR if this takes awhile to land.
Here's some benchmarks:
Performance looks to be about the same or maybe slightly faster. The benefit is really just that it's a huge simplification of the code.
cc @nodejs/diagnostics