You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
AS A Node.js developer
I WANT to not spend more wall-clock time disposing of async resources than necessary
SO THAT my applications do not feel sluggish compared to other languages
Resources have construction dependencies, which are naturally expressed by having to pass dependencies as arguments, e.g.
When disposing of these resources, it's reasonable but not correct to assume that there is a LIFO destruction order requirement. In theory, if you know that myFrobnicatorService does not retain a reference to mySession, you can dispose of both resources in parallel, without waiting for myFrobnicatorService to dispose first before starting to dispose of mySession.
This issue naturally extends to more complex DAGs of dependency relationships (equivalently, lifetime constraints). Crucially, you cannot in general infer anything about the optimal disposal plan.
Just as a starting point for a solution, perhaps having a protocol for a resource[Symbol.resourceDependencies] property which returns a Set of resources, can give us the information we need to dispose of things with the shortest critical path, i.e. disposing of resources as soon as they no longer have dependents. If this [Symbol.disposeDependencies] property is undefined, then fall back to LIFO disposal.
Thanks
The text was updated successfully, but these errors were encountered:
How many things are you tearing down? Also, keep in mind, other languages with deterministic destructors like C++ and Rust also do it sequentially, and Rust's own AsyncDrop proposal is sequential.
A AsyncDisposableGroup type could solve this, but IMHO it's worth punting to a follow-on (I'm not TC39, so not my decision).
AS A Node.js developer
I WANT to not spend more wall-clock time disposing of async resources than necessary
SO THAT my applications do not feel sluggish compared to other languages
Resources have construction dependencies, which are naturally expressed by having to pass dependencies as arguments, e.g.
When disposing of these resources, it's reasonable but not correct to assume that there is a LIFO destruction order requirement. In theory, if you know that
myFrobnicatorService
does not retain a reference tomySession
, you can dispose of both resources in parallel, without waiting formyFrobnicatorService
to dispose first before starting to dispose ofmySession
.This issue naturally extends to more complex DAGs of dependency relationships (equivalently, lifetime constraints). Crucially, you cannot in general infer anything about the optimal disposal plan.
Just as a starting point for a solution, perhaps having a protocol for a
resource[Symbol.resourceDependencies]
property which returns aSet
of resources, can give us the information we need to dispose of things with the shortest critical path, i.e. disposing of resources as soon as they no longer have dependents. If this[Symbol.disposeDependencies]
property is undefined, then fall back to LIFO disposal.Thanks
The text was updated successfully, but these errors were encountered: