-
Notifications
You must be signed in to change notification settings - Fork 30k
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
async_hooks: stabilize part of AsyncLocalStorage #37675
async_hooks: stabilize part of AsyncLocalStorage #37675
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is still a Stability: 1 - Experimental
on top for the whole module.
Maybe we should remove it there and add it instead at Class: AsyncHook
and Class: AsyncResource
?
Don't know who this is usually handled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
@Flarna , I don't either ^^ Maybe someone over @nodejs/documentation knows what's the best way to do it here? |
@vdeturckheim what about creating new page2 for AsyncResouce and AsyncLocalStorage ? I think that makes sense as they are each a unique concept/api (although related) on their own, and if for example we ended up deprecating the lower level async hooks they could still stand on their own. I also think that would be less confusing in terms of what is experimental or not as well as being able to directly reference AsyncResouce |
I'm a little -0 on giving them their own import specifier / page. I think having all these diagnostic and power tools in a single place really lets the organization be closer to purpose rather than purely on API stability. I'm fine if a new page is done, but would be -1 on changing the import specifier unless there was a clearer checklist of what should cause such a change for other APIs in the future. |
I was not suggesting changing the import specifier, just the organization of the docs. |
👍 for splitting up the docs. If we're splitting the doc up here anyway, perhaps we should also include |
@vdeturckheim that sounds reasonable to me. |
So both |
@vdeturckheim being split out looks good. I'm thinking it might make sense to put the AsyncLocalStorage part first as it seems like the simpler of the two, and one of the key reasons you need AsyncResource is to keep AsyncLocalStorage working properly in a subset of the cases so seems like a good thing to follow AsyncLocalStorage. WDYT? Just a suggestion as I'd be good either way once the TODO's are filled in. |
@mhdawson agreed. I updated a bit. It should start to look good now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like a good start. A few thoughts:
Should AsyncLocalStorage
and AsyncResource
get separate pages, and related--should we aim to make them separate top-level modules eventually?
Should the requireManualDestroy
option and emitDestroy
method of AsyncResource
remain experimental? They're perhaps a bit janky as far as features go, and one could draw some parallels to the unsafety of domains in there, though I'm not too worried about it. Perhaps just a warning about timing of the destroy?
For the intro, it would be good to elaborate on the relationship between AsyncLocalStorage
on the consuming end and AsyncResource
on the producing end of async context propagation semantics.
Co-authored-by: Michaël Zasso <[email protected]> Co-authored-by: Andrey Pechkurov <[email protected]>
Signed-off-by: Michael Dawson <[email protected]>
Signed-off-by: Michael Dawson <[email protected]>
Doc only, so full CI not required. |
@bmeck @Qard @mcollina @bengl @vdeturckheim FYI as long as the github actions all pass I'll plan to land this tomorrow in case you want to take another look. I think I've fixed up all the things I talked with @vdeturckheim about (unless there is more that the actions run which make test locally does not run). |
@mcollina thanks for the heads up. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had some comments on doc/api/async_context.md
, but only after I had reviewed it and prepared them all did I realize that that page wasn't written in this PR, it was only moved. 😆 I'll submit my suggestions in a new PR once this is merged.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
Mark AsyncLocalStorage constructor, AsyncLocalStorage.prototype.getStore(), and AsyncLocalStorage.prototype.run as stable. PR-URL: #37675 Reviewed-By: Bradley Farias <[email protected]> Reviewed-By: Andrey Pechkurov <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Stephen Belanger <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Gerhard Stöbich <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Bryan English <[email protected]>
Landed in 7612d82 @vdeturckheim thanks for all your work on this. |
Mark AsyncLocalStorage constructor, AsyncLocalStorage.prototype.getStore(), and AsyncLocalStorage.prototype.run as stable. PR-URL: #37675 Reviewed-By: Bradley Farias <[email protected]> Reviewed-By: Andrey Pechkurov <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Stephen Belanger <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Gerhard Stöbich <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Bryan English <[email protected]>
PR-URL: #39031 Notable changes: * async_hooks: * stabilize part of AsyncLocalStorage (Vladimir de Turckheim) #37675 * deps: * upgrade npm to 7.18.1 (npm-robot) #39065 * update V8 to 9.1.269.36 (Michaël Zasso) #38273 * dns: * allow `--dns-result-order` to change default dns verbatim (Ouyang Yadong) #38099
Notable changes: * async_hooks: * stabilize part of AsyncLocalStorage (Vladimir de Turckheim) #37675 * deps: * upgrade npm to 7.18.1 (npm-robot) #39065 * update V8 to 9.1.269.36 (Michaël Zasso) #38273 * dns: * allow `--dns-result-order` to change default dns verbatim (Ouyang Yadong) #38099 PR-URL: #39031
Notable changes: * async_hooks: * stabilize part of AsyncLocalStorage (Vladimir de Turckheim) #37675 * deps: * upgrade npm to 7.18.1 (npm-robot) #39065 * update V8 to 9.1.269.36 (Michaël Zasso) #38273 * dns: * allow `--dns-result-order` to change default dns verbatim (Ouyang Yadong) #38099 PR-URL: #39031
Notable changes: * async_hooks: * stabilize part of AsyncLocalStorage (Vladimir de Turckheim) #37675 * deps: * upgrade npm to 7.18.1 (npm-robot) #39065 * update V8 to 9.1.269.36 (Michaël Zasso) #38273 * dns: * allow `--dns-result-order` to change default dns verbatim (Ouyang Yadong) #38099 PR-URL: #39031
This PR stabilizes part of the
AsyncLocalStorage
API.The whole reasoning for chosing this subset of methods was discussed in #35286 (comment)
cc @bmeck @Qard @mhdawson @mcollina @bengl