Deprecate destroy hook of async_hooks

[legendecas]

With async_hooks.executionResource(#30959 ) and async_hooks.AsyncLocalStorage(#26540) landed on master, APM and continuation local storage users can use only the init hook and async_hooks.AsyncLocalStorage, which is also only used the init hook.

In the context of that removing destroy hook can introduce a considerable performance improvement possibilities on async_hooks enabled, is it appropriate to deprecate the destroy hook now?

[legendecas]

/cc @nodejs/async_hooks @nodejs/diagnostics

[Flarna]

Please note that there are other users then CLS/APMs for async_hooks which would like to track lifetime of resources. These user cases still need the destroy hook therefore I'm not sure if deprecation is the right approach.

It's also not yet proven that async_hooks.executionResource is applicable to all CLS usecases. For example node core is not yet using it for domains. I know that domains are deprecated but I still see them as sample for an advanced use of async hooks.

[addaleax]

Also, keep in mind that the destroy hook should not be adding a lot of overhead anyway when there are no destroy hooks currently enabled.

[legendecas]

Also, keep in mind that the destroy hook should not be adding a lot of overhead anyway when there are no destroy hooks currently enabled.

Yeah, the overhead is not introduced by destroy hook directly. But as stated in Promise Hooks Proposal, removing destroy hooks and make the lifetime tracking optional by WeakRefs can reduce the overhead of promise hooks.

Any idea?

[Flarna]

Maybe ask v8 team to add an option to SetPromseHook API which types it should report or add a dedicated API to register a destroy hook?
As long as there is no user of async_hooks installing a destroy hook it's not installed/enabled.

[legendecas]

@Flarna IIRC, Promise hook doesn't provide a destroy callback. It's wrapped in node with weak global reference by PromiseWrap.

[mcollina]

I'm -1 in removing the destroy hook because it's highly useful for tracking actual disposal of underlining resources (sockets, files, etc..).

From my point of view we should avoid tracking the lifetime of promises if it is not needed.

[Flarna]

@legendecas You are right. That's all within node.
As promises are resources is needed for async_hooks.executionResource to track them; at least the creation otherwise any CLS system will fails to work once await or a Promise is used.

i don't know which part of the current design is actually causing the overhead we could get rid of.

[naugtur]

As a user of async hooks, eg. here https://github.com/naugtur/blocked-at/
I'm interested in keeping the destroy available.

I could use async local storage, but I loose control of its size. If I want to create a limited cache where it keeps only some of the items according to custom logic, I need the destroy hook to know which are no longer needed.

I haven't implemented such a cache in the linked project yet, but I did consider it. Without destroy hook I can only save all and get them cleaned up, but can't choose to drop some earlier to save on space

That's just one example. Hope it helps.

[jasnell]

Please don't :-) ... the destroy hook is important in diagnostic tooling that tracks the lifetime of objects for analysis purposes. Yes, it introduces a performance hit but that's ok. What we should do instead is document that it is not needed in most cases but we still do need the hook

[legendecas]

Thanks all for the very detailed explanation!! Seems like this is not the best direction to address the performance issue of async hooks. Given the suggestions above, I'm going to close this and seeking a better solution.

[puzpuzpuz]

Does it make sense to create another issue for not emitting destroy events for async resources (including promises) when there are no active destroy hooks?

I don't know how expensive AsyncWrap::WeakCallback is (I may be wrong when pointing to this method) and whether this or something else in PromiseWrap acts as a bottleneck in AsyncLocalStorage use case, so any feedback from async_hooks maintainers is welcome.