async_hooks: fix Promises with later enabled hooks

[addaleax]

Based on #13224

Fixes: #13237

/cc @AndreasMadsen @matthewloring @Fishrock123 @nodejs/diagnostics

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• commit message follows commit guidelines

Affected core subsystem(s)

async_hooks

[AndreasMadsen]

well, this is a fun hack :) – I'm not sure I approve, would a default parameter in AsyncWrap::AsyncWrap and AsyncWrap::AsyncReset be that difficult?

@Fishrock123 thoughts?

[addaleax]

would a default parameter in AsyncWrap::AsyncWrap and AsyncWrap::AsyncReset be that difficult?

@AndreasMadsen yeah no you’re right. done. 😄

[AndreasMadsen]

LGTM.

Although, I do think we should use

uint32_t* fields_ptr = async_hooks->fields();
if (fields_ptr[AsyncHooks::kInit] +
    fields_ptr[AsyncHooks::kBefore] +
    fields_ptr[AsyncHooks::kAfter] +
    fields_ptr[AsyncHooks::kDestroy] > 0) {

}

instead of #13177 for a more consistent performance, when createHook() has been called but no hooks are enabled. But that is not relevant in this PR.

[addaleax]

@AndreasMadsen Yes, I see no problem with doing that too; but I would really like to keep the SetPromiseHook() call lazy so that non-async_hooks users don’t pay the price for it.

[AndreasMadsen]

Yes, I see no problem with doing that too; but I would really like to keep the SetPromiseHook() call lazy so that non-async_hooks users don’t pay the price for it.

Makes sense.

edit: the goal is that there is no difference between calling .disable() and never having called require('async_hooks'), but that is not a trivial task and is likely over-optimistic.

[matthewloring]

This looks good on my end. Sorry for the lack of bandwidth to address this on #13224 directly.

[addaleax]

@matthewloring No problem! This PR is me cleaning up my own mistake. If you want you can still cherry-pick 0ec3eba0534f7de36c6c2e8baa38188a5279727f into your PR so that it can land a bit earlier.

[matthewloring]

As long as it gets in to node 8 I'm happy either way :)

[addaleax]

the goal is that there is no difference between calling .disable() and never having called require('async_hooks'), but that is not a trivial task and is likely over-optimistic

It shouldn’t be so terribly hard either. Maybe I can take a look after the current bunch of async_wrap PRs are through.

As long as it gets in to node 8 I'm happy either way :)

@matthewloring Yeah, me too. Maybe we should ask @nodejs/collaborators whether they think it’s a good idea to fast-track this? At this point you and @AndreasMadsen seem to be “the” most relevant reviewers for async_hooks by far… (speaking of which, would you mind giving #13142 a look? 😬)