async_wrap,src: promise hook integration #13000

matthewloring · 2017-05-12T17:52:52Z

This change provides unified tracking of asynchronous promise lifecycles
for both domains and async hooks.

Checklist

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

Affected core subsystem(s)

async_wrap,src

This change provides unified tracking of asynchronous promise lifecycles for both domains and async hooks.

matthewloring · 2017-05-12T17:53:31Z

Here is the work I have so far on promise integrations for domains/async hooks. There are a few outstanding things I wanted to discuss:

Currently promises do not have an internal field slot that can be used by BaseObject. To get around this, we create a separate object stored on the promise that can be wrapped and delegate domain lookups to that object. Maybe @gsathya has a better approach for this or could comment on the feasibility of having an internal field added to the promise object template.
It would be good to surface additional information that promise hooks makes available through async hooks. Specifically, promise hooks gives information about parent-child relationships when promises are constructed as part of a chain. It would be nice to pass metadata to the async hook callbacks that could relay this (or maybe there is already a pattern in place for making this available). Also, some diagnostic tools (specifically for resource tracking) are interested in knowing when promises resolve in addition to the "before" and "after" events. Maybe we could consider adding a resolution async hook event (potentially this could be used by other resource types other than just promises). I wrote up some more thoughts on this here.
It would be good to get a review from someone with more understanding of test-async-wrap=-getasyncid.js to figure out the right way of exposing the promise wrap object to JS.

Fishrock123 · 2017-05-12T18:11:45Z

My quick thoughts on (2.) is that it would probably be better have the returned Resource Object be it's own abstracted information object rather than the Promise itself. It can still have the actual Promise as a property or getter if necessary.

AndreasMadsen · 2017-05-12T18:16:31Z

src/async-wrap.cc

@@ -201,6 +332,7 @@ static void SetupHooks(const FunctionCallbackInfo<Value>& args) {
  SET_HOOK_FN(before);
  SET_HOOK_FN(after);
  SET_HOOK_FN(destroy);
+  env->isolate()->SetPromiseHook(PromiseHook);


If I'm reading this correct, this means that we only have domain support for promises when async_wrap is enabled. That might be okay if we enable async_wrap when domain is used, but as it is now this makes the behavior of domain depend on the state of async_hooks.

Ack, please use AddPromiseHook instead. :)

Updated to use AddPromiseHook.

addaleax · 2017-05-12T18:14:25Z

src/async-wrap.cc

+  Local<Context> context = info.GetIsolate()->GetCurrentContext();
+  Environment* env = Environment::GetCurrent(context);
+  info.GetReturnValue().Set(Object::Cast(*info.Data())->Get(context,
+                            env->domain_string()).ToLocalChecked());


The alignment is off here, and we don’t usually dereference handles unless there’s a reason to. This should work:

info.GetReturnValue().Set( info.Data().As<Object>()->Get(context, env->domain_string()).ToLocalChecked());

addaleax · 2017-05-12T18:20:06Z

src/async-wrap.cc

+    Local<Object> obj = tem->NewInstance(context).ToLocalChecked();
+    PromiseWrap* wrap = new PromiseWrap(env, obj);
+    promise->DefineOwnProperty(context,
+              FIXED_ONE_BYTE_STRING(env->isolate(), async_id_key),


Instead of using FIXED_ONE_BYTE_STRING, you may want to add to the string list in env.h (to avoid creating strings over and over again)

addaleax · 2017-05-12T18:20:22Z

src/async-wrap.cc

@@ -201,6 +332,7 @@ static void SetupHooks(const FunctionCallbackInfo<Value>& args) {
  SET_HOOK_FN(before);
  SET_HOOK_FN(after);
  SET_HOOK_FN(destroy);
+  env->isolate()->SetPromiseHook(PromiseHook);


Ack, please use AddPromiseHook instead. :)

addaleax · 2017-05-12T18:21:37Z

src/node.cc

-void AddPromiseHook(v8::Isolate* isolate, promise_hook_func fn, void* arg) {
-  Environment* env = Environment::GetCurrent(isolate);
-  env->AddPromiseHook(fn, arg);
-}


This should stay, it was intentionally requested for the public API so that Node using the single PromiseHook slot doesn’t block others from doing the same.

If this lands in Node 8, then at least our need for AddPromiseHook is gone. It is only if these promise hooks don't make it into async_wrap in Node 8 as publicly documented features that we needed to share the promise hook.

I removed a little more than intended. This has been added back in.

AndreasMadsen · 2017-05-12T18:24:50Z

test/parallel/test-async-wrap-getasyncid.js

@@ -66,6 +66,12 @@ function testInitialized(req, ctor_name) {
 }


+{
+  // TODO: determine the rigth way to expose promise wrap.
+  new Promise((res) => res(5));


I don't think we need to expose the PromiseWrap on the new Promise object. PromiseWrap just has to be the resource object in the init hook, and the PromiseWrap object has to point to the new Promise object.

We don't expose *Wrap objects to userland in any other way than through the async_hooks resource object.

So does this mean that we do not need to expose a "getAsyncId" operation for promises (adding it will have performance implications so it would be great if it isn't needed)?

Correct. I don't see any reason for getAsyncId to be exposed on promises.

Updated the comment to reflect this.

AndreasMadsen · 2017-05-12T18:32:05Z

src/async-wrap.cc

+                           GetPromiseDomain, NULL, obj).FromJust();
+    }
+  } else if (type == PromiseHookType::kResolve) {
+    // TODO(matthewloring): need to expose this through the async hooks api.


kResolve only happens once per promise, when the promise is resolved, right? In that case, I think we can just put the current async id that caused the resolve on the PromiseWrap object. That should provide most of the additional information.

Yes, there is also the actual event but that information can be inferred when kBefore is emitted. In case .then() is never called, I don't this it is that interesting when the promise is resolved since it is never used.

kResolve only happens once per promise

yep :)

when the promise is resolved, right?

You’d think so, wouldn’t you? 😄 This isn’t called when the promise is resolved, it’s at the beginning of when the resolve function (as in new Promise((resolve) => …)) or some equivalent of it is called. That might not be when the Promise is resolved, though (because you can call resolve() with other pending promises).

I’m not actually sure kResolve is a very interesting thing for async hooks?

I'm not sure if a promise's then correlates with kResolve, but a promise's then can be called multiple times.

This isn’t called when the promise is resolved, it’s at the beginning of when the resolve function (as in new Promise((resolve) => …)) or some equivalent of it is called.

Haha, that was actually what I meant, when resolve() is called. I always mix up my promise terminology.

I’m not actually sure kResolve is a very interesting thing for async hooks?

This was perhaps the most discussed thing in the async_hooks EPS. This comment descibes the two viewpoints nodejs/node-eps#18 (comment), though I don't really agree with the "who needs what" part (stack-trace vs CLS) after talking with APM providers (@watson).

I think adding the async id that called resolve() to the PromiseWrap is the best option for satisfying both parties.

This is an example scenario that almost captures all the possibilities that Promises and async hooks can interact:

(function runner() { const p = new Promise(function p_fn0(res) { setImmediate(function si0() { res('foo') }); }).then(function then0(val) { return Fn(val); }); setImmediate(function si0() { p.catch(function catch0(err) { printLongErrorStack(err); // not defined }); }); function Fn(val) { if (val === 'foo') throw new Error('bam'); } })();

If each Promise executor, onFulfilled or onRejected only collect the stack when new Promise() or .then() runs then the stack would be:

at printLongErrorStack at catch0 at si0 at runner

Though it would be helpful to produce the following long stack:

at printLongErrorStack at catch0 at Fn at then0 at si0 at p_fn0 at runner

I've had some lengthy discussions about this and, though I don't remember with whom, I recall agreeing that the logical place to execute the AsyncEvent hooks would produce the first call stack; but it should also be possible to produce the second call stack (@matthewloring was this conversation with you?).

So for this PR the first stack above is expected, but we should also address how to produce the second. IIRC the API in in place to allow watching for resolve or reject calls. At which point a stack can be produced then (somehow?) attached to the Promise handle that's responsible for the current execution scope.

Yup, this conversation was with me and I think it captures the concern with attaching the async id to the promise resource at resolution time so that it can be read in kBefore. This approach does not allow async_hook users to "react" to a promise resolution (state cannot be observed/updated at resolution time). Would it be too much to add another async_hook type for the resolution of async work (promise or otherwise)? With the addition of the C++ embedder api I can imagine that other types of async work could notify when async operations completes even if the JS callback isn't invoked immediately.

@matthewloring Adding another type that fires at a different time wouldn't be a problem.

This approach does not allow async_hook users to "react" to a promise resolution (state cannot be observed/updated at resolution time). Would it be too much to add another async_hook type for the resolution of async work (promise or otherwise)? With the addition of the C++ embedder api I can imagine that other types of async work could notify when async operations completes even if the JS callback isn't invoked immediately.

While it is not a technical issue to add another type (I assume you mean event type and not resource type), I think it would be better to do in a future PR where we have a better chance to evaluate the needs for such event type for other cases than promises.

So far the only concern mentioned in the EPS has been regarding context across async boundaries, which "attaching the async id to the promise resource" does solve, although not in a particularly nice way.

Addressing this in a follow on seems fine to me.

gsathya · 2017-05-15T19:58:41Z

Maybe @gsathya has a better approach for this or could comment on the feasibility of having an internal field added to the promise object template.

The current approach seems fine to me. You can use a private symbol if you don't think this should be exposed.

LGTM. Thanks for implementing this!

matthewloring · 2017-05-15T23:58:43Z

src/async-wrap.cc

+  Environment* env = Environment::GetCurrent(context);
+  const char async_id_key[] = "__async_wrap";
+  const char tag_id_key[] = "__async_wrap_tag";
+  if (type == PromiseHookType::kInit) {


Is there an analogue of env->in_domain() for async_hooks? It would be good to bail out here if we know async hooks is not enabled.

@matthewloring What Trevor has been doing elsewhere in the code is testing env()->async_hooks()->fields()[AsyncHooks::kInit] == 0, I think that should work.

I still like the AddPromiseHook approach, though – it helps with keeping domains and async hooks separate, and more importantly I think we’d only want to set a promise hook if we’re actually consuming the information. Otherwise it seems like something that might come with unnecessary performance impact on Promise usage. Seems like that has already been addressed, sorry.

@addaleax As far as I can tell, the line above is only used to avoid invoking init hooks if none have been registered. I was hoping to avoid attaching the new async hook related properties to promises in the case where async hooks were disabled. Adding these properties causes ~30x increase in the time it takes to construct/resolve promises (adding the property causes all of V8's map checks to fail and prevent promises from ever running on fast paths). I am hoping to fix this by adding an internal field to promises (https://codereview.chromium.org/2889863002/) but it would be good to avoid modifying promises if async hooks are not in use.

This slow down may also come in to play when domains are active as that also seems to modify promise shape but I haven't run any benchmarks against domains yet.

@matthewloring I think this might be enough for what you want? I didn’t try it with this PR but it passes testing on its own.

diff

diff --git a/lib/async_hooks.js b/lib/async_hooks.js index 867b5eb52da1..49f8fa5becf2 100644 --- a/lib/async_hooks.js +++ b/lib/async_hooks.js @@ -49,12 +49,7 @@ const before_symbol = Symbol('before'); const after_symbol = Symbol('after'); const destroy_symbol = Symbol('destroy'); -// Setup the callbacks that node::AsyncWrap will call when there are hooks to -// process. They use the same functions as the JS embedder API. -async_wrap.setupHooks({ init, - before: emitBeforeN, - after: emitAfterN, - destroy: emitDestroyN }); +let setupHooksCalled = false; // Used to fatally abort the process if a callback throws. function fatalError(e) { @@ -103,6 +98,16 @@ class AsyncHook { if (hooks_array.includes(this)) return; + if (!setupHooksCalled) { + setupHooksCalled = true; + // Setup the callbacks that node::AsyncWrap will call when there are + // hooks to process. They use the same functions as the JS embedder API. + async_wrap.setupHooks({ init, + before: emitBeforeN, + after: emitAfterN, + destroy: emitDestroyN }); + } + // createHook() has already enforced that the callbacks are all functions, // so here simply increment the count of whether each callbacks exists or // not.

I was hoping to avoid attaching the new async hook related properties to promises in the case where async hooks were disabled.

How much will inverting the dependencies help, as suggested in #13000 (comment)? Personally, I see no reason to add properties to the promise object.

@addaleax yes, but can a WeakMap (wrap = map[promise]) not be used to get around setting properties?

@AndreasMadsen As I’ve recently learned, no :( http://iamstef.net/n/shapeshifting.html

I see, that is sad :(

@matthewloring I actually had a call like this previously, but removed it b/c it wasn't needed anywhere in the initial PR. Basically if kInit == !(kBefore == !(kAfter == !(kDestroy == 0))) then the hooks list is empty. I had consolidated this into kTotalHooks that was the sum of all active hooks, so the only necessary check was kTotalHooks == 0. I can re-add this if necessary easily. Already have the code from the previous implementation.

Just noting that @addaleax's suggestion above has been pulled to here to separate the discussion.

joshgav · 2017-05-16T20:02:43Z

@matthewloring

Specifically, promise hooks gives information about parent-child relationships when promises are constructed as part of a chain. It would be nice to pass metadata to the async hook callbacks that could relay this (or maybe there is already a pattern in place for making this available).

I think trigger_id is meant to serve as the parent context ID. It's made available to init hooks here and seems that it should be available as the second parameter to before hooks (see e.g. here); but the before hook implementation of trigger_id seems incomplete here.

addaleax

Looks mostly good. I’d have a preference for https://github.com/nodejs/node/pull/13000/files#r117075597 to be used here, but I can also PR that separately if you prefer.

addaleax · 2017-05-18T13:23:21Z

src/async-wrap.cc

+  Local<Context> context = promise->CreationContext();
+  Environment* env = Environment::GetCurrent(context);
+  const char async_id_key[] = "__async_wrap";
+  const char tag_id_key[] = "__async_wrap_tag";


These two seem to be unused now?

These were removed in 0afbcfc. Thanks.

addaleax · 2017-05-18T13:25:20Z

src/async-wrap.cc

+  Local<v8::Value> external_wrap =
+      promise->Get(context, env->promise_async_id()).ToLocalChecked();
+  PromiseWrap* wrap =
+    static_cast<PromiseWrap*>(v8::External::Cast(*external_wrap)->Value());


Getting a déjà-vu, maybe I already commented before, but we generally prefer not to dereference handles explicitly (i.e. using external_wrap.As<v8::External>()->Value() is fine)

@addaleax Don't they basically result in the same operation? e.g. from class Local:

template <class S> V8_INLINE Local<S> As() const { return Local<S>::Cast(*this); }

@matthewloring To satiate my paranoia, mind adding a CHECK_NE(wrap, nullptr) just below?

@trevnorris Yes, sorry for not being clear; they result in the same compiled code. This was just a style thing, the overwhelming majority of our codebase uses .As<>(), that’s all.

@addaleax Added the check here 34ee31f

addaleax · 2017-05-18T13:26:21Z

src/node.cc

@@ -1208,8 +1155,6 @@ void SetupDomainUse(const FunctionCallbackInfo<Value>& args) {
  Local<ArrayBuffer> array_buffer =
      ArrayBuffer::New(env->isolate(), fields, sizeof(*fields) * fields_count);

-  env->AddPromiseHook(DomainPromiseHook, static_cast<void*>(env));


Is this being removed intentionally?

addaleax · 2017-05-18T13:27:55Z

src/async-wrap.cc

+      obj->Set(context, env->domain_string(),
+        env->domain_array()->Get(context, 0).ToLocalChecked()).FromJust();
+      promise->SetAccessor(context, env->domain_string(),
+                           GetPromiseDomain, NULL, obj).FromJust();


Is there anything speaking against removing the domain handling inside this promise hook and re-adding the DomainPromiseHook? That way we don’t have to pay for domains or async hooks if we don’t use them

My goal with the refactor was to try and have the domain entry and exit logic + promise hook before/after logic live in one place to avoid having complex parallel code in multiple places. I think this can be achieved with re-adding DomainPromiseHook (it is also highly unlikely that a project would use both domains and async hooks so keeping them logically separated would be good).

Yea, I get what you were aiming at, and I do like the idea a lot. But I’d just rather prefer not to have domain usage depend on using async hooks, that’s all; I don’t care that much how that’s done.

(I.e. don’t assume I’d think the solution I pushed here is optimal – I’m sure there’s room for improvement)

trevnorris

Great work here. Have a few things, and let me know if you'd like an assist.

trevnorris · 2017-05-19T20:35:44Z

src/async-wrap.cc

+      if (enter_v->IsFunction()) {
+        if (enter_v.As<Function>()->Call(domain, 0, nullptr).IsEmpty()) {
+          FatalError("node::AsyncWrap::MakeCallback",
+                    "domain enter callback threw, please report this");


style nit: align arguments

@addaleax Fixed this here 5717d75.

trevnorris · 2017-05-19T20:43:34Z

src/async-wrap.cc

+    if (ar.IsEmpty()) {
+      ClearFatalExceptionHandlers(wrap->env());
+      FatalException(wrap->env()->isolate(), try_catch);
+      return false;


FatalException() always exits the application in this case because ClearFatalException() removed all unhandledException callbacks. So I'll assume this return is so the compiler doesn't emit a warning.

I decided this would be the safest course of action when first implementing AsyncWrap because it was difficult to properly clean up if an async hook threw. It was difficult enough to properly cleanup if a user's callback threw (see process._fatalException() in lib/internal/bootstrap_node.js). If we can properly show it's safe to recover from an async hook throwing then I'm all for changing this behavior.

That makes sense, maybe we can look into that more in a follow on pr.

trevnorris · 2017-05-19T20:49:24Z

src/async-wrap.cc

+    // Unfortunately, promises don't have internal fields. Need a surrogate that
+    // async wrap can wrap.
+    Local<v8::ObjectTemplate> tem = v8::ObjectTemplate::New(env->isolate());
+    tem->SetInternalFieldCount(1);


Would it be faster to create an Eternal<ObjectTemplate> (e.g. adding this to ENVIRONMENT_STRONG_PERSISTENT_PROPERTIES() in src/env.h) that can be reused for all NewInstance().

The need for a custom object template will be going away as soon as we move to an internal property on promises (blocked on #13175). I can modify this but I intend to get the promise internal property refactoring in before 8.0.

I've added this for now.

trevnorris · 2017-05-19T20:51:26Z

src/async-wrap.cc

+              v8::PropertyAttribute::DontEnum).FromJust();
+    promise->DefineOwnProperty(context,
+              env->promise_async_tag(),
+              obj, v8::PropertyAttribute::DontEnum).FromJust();


Do we want the user to be able to alter these? In src/async-wrap.cc I used

v8::PropertyAttribute ReadOnlyDontDelete = static_cast<v8::PropertyAttribute>(v8::ReadOnly | v8::DontDelete);

Though I probably should have added DontEnum to that list.

This property will be going away as soon as we move to an internal property on promises (blocked on #13175). I can modify this but I intend to get the promise internal property refactoring in before 8.0.

I've added this for now.

trevnorris · 2017-05-19T21:53:38Z

src/async-wrap.cc

+                           GetPromiseDomain, NULL, obj).FromJust();
+    }
+  } else if (type == PromiseHookType::kResolve) {
+    // TODO(matthewloring): need to expose this through the async hooks api.


This is an example scenario that almost captures all the possibilities that Promises and async hooks can interact:

(function runner() { const p = new Promise(function p_fn0(res) { setImmediate(function si0() { res('foo') }); }).then(function then0(val) { return Fn(val); }); setImmediate(function si0() { p.catch(function catch0(err) { printLongErrorStack(err); // not defined }); }); function Fn(val) { if (val === 'foo') throw new Error('bam'); } })();

If each Promise executor, onFulfilled or onRejected only collect the stack when new Promise() or .then() runs then the stack would be:

at printLongErrorStack at catch0 at si0 at runner

Though it would be helpful to produce the following long stack:

at printLongErrorStack at catch0 at Fn at then0 at si0 at p_fn0 at runner

I've had some lengthy discussions about this and, though I don't remember with whom, I recall agreeing that the logical place to execute the AsyncEvent hooks would produce the first call stack; but it should also be possible to produce the second call stack (@matthewloring was this conversation with you?).

So for this PR the first stack above is expected, but we should also address how to produce the second. IIRC the API in in place to allow watching for resolve or reject calls. At which point a stack can be produced then (somehow?) attached to the Promise handle that's responsible for the current execution scope.

trevnorris · 2017-05-19T21:54:47Z

src/async-wrap.cc

-  // Want currentId() to return the correct value from the callbacks.
-  AsyncHooks::ExecScope exec_scope(env(), get_id(), get_trigger_id());
+  Environment::AsyncHooks::ExecScope exec_scope(env(),
+                                                get_id(),


Grabbing the Local<Context> using Environment isn't free. Maybe pass it in?

Grabbing the Local<Context> using Environment isn't free

Are you sure? We use the StrongPersistentToLocal utility to get a Local out of the Persistent properties, which is somewhat icky but should compile down to a no-op.

@addaleax Note sure what I was smoking. My comment makes no sense. Never mind.

trevnorris · 2017-05-19T22:03:08Z

src/async-wrap.cc

+  Local<v8::Value> external_wrap =
+      promise->Get(context, env->promise_async_id()).ToLocalChecked();
+  PromiseWrap* wrap =
+    static_cast<PromiseWrap*>(v8::External::Cast(*external_wrap)->Value());


@addaleax Don't they basically result in the same operation? e.g. from class Local:

template <class S> V8_INLINE Local<S> As() const { return Local<S>::Cast(*this); }

@matthewloring To satiate my paranoia, mind adding a CHECK_NE(wrap, nullptr) just below?

addaleax · 2017-05-21T15:22:03Z

@matthewloring I went ahead and pushed fixes for some of mine and Trevor’s review comments to this PR, feel free to remove anything that you disagree with.

Edit: Just so you know, I’m especially unsure about the last commit. I think it makes sense, but I’m not 100 % sure.

@trevnorris @AndreasMadsen Please take a look, and it would be great if you could pinpoint what you think should definitely be changed before this is ready to land.

CI: https://ci.nodejs.org/job/node-test-commit/10055/

AndreasMadsen

LGTM. But @trevnorris should approve before merging.

Left a few comments, mostly just nits and questions.

AndreasMadsen · 2017-05-21T17:07:10Z

src/async-wrap.cc

+    Local<Object> obj = tem->NewInstance(context).ToLocalChecked();
+    PromiseWrap* wrap = new PromiseWrap(env, obj);
+    promise->DefineOwnProperty(context,
+              env->promise_async_id(),


nit: async_id is confusion as that indicates this store the double id. But in reality, it stores the PromiseWrap object. Maybe calling it env->promise_wrap() would be better.

AndreasMadsen · 2017-05-21T17:09:04Z

src/async-wrap.cc

+              v8::External::New(env->isolate(), wrap),
+              v8::PropertyAttribute::DontEnum).FromJust();
+    promise->DefineOwnProperty(context,
+              env->promise_async_tag(),


What is promise_async_tag() used for, preventing garbage collection? If so I think a comment should be added.

The only reference to it is held by the promise. We use its lifespan to approximate when the promise was garbage collected. I've added a comment describing this.

AndreasMadsen · 2017-05-21T17:15:38Z

test/async-hooks/test-promise.js

+}
+
+process.on('exit', onexit);
+function onexit() {


We don't check the destroy hook. I'm okay with skipping it because it involves the gc and that can be a bit fiddly. But a comment should be added explaining why it isn't checked.

addaleax · 2017-05-23T19:23:36Z

@matthewloring The nice thing about e1c11e7 should be that the performance impact would only apply if one is using async hooks, so it doesn’t affect regular promise users.

matthewloring · 2017-05-23T19:26:51Z

e1c11e7 makes things faster when async hooks is disabled. #13175 makes things faster when they are enabled. I think we want both in the final product.

addaleax

Didn’t go through the test in detail but generally LGTM

addaleax · 2017-05-23T19:26:59Z

src/async-wrap.cc

+  info.GetReturnValue().Set(
+      info.Data().As<Object>()->Get(context,
+                                    env->domain_string()).ToLocalChecked());
+}


I guess I missed that, but you can drop this (and the if (env->in_domain()) { block that installs it, too) now

addaleax · 2017-05-23T19:29:01Z

I think we want both in the final product.

Definitely, yes! I’m just eyeing a bit on the 8.0.0 release date, that’s all.

matthewloring · 2017-05-23T19:31:15Z

If we modify the shape of promises in this PR and then revert that after the 8.0 release will that be considered breaking? I would be ok working the promise internal field changes in afterwards if we can be pretty sure it will land.

matthewloring · 2017-05-23T19:32:06Z

In either case, I'll look into addressing the rest of Trevor's comments this afternoon.

addaleax · 2017-05-23T19:33:44Z

If we modify the shape of promises in this PR and then revert that after the 8.0 release will that be considered breaking?

I don’t think so; I’d say it’s obvious those fields are internal, and we do consider async_hooks an experimental feature so I think we have the liberty to make that change.

I would be ok working the promise internal field changes in afterwards if we can be pretty sure it will land.

You can also rebase this PR on #13175 now, if you think that makes the most sense :) We’ll just consider this blocked until #13175 lands then.

matthewloring · 2017-05-24T16:45:25Z

@trevnorris I think your comments should be addressed. Could you take another look.

AndreasMadsen

LGTM

As far as I can tell, this has been addressed.

addaleax · 2017-05-24T18:28:57Z

Fresh CI: https://ci.nodejs.org/job/node-test-commit/10133/

matthewloring · 2017-05-25T00:24:16Z

New CI run is green: https://ci.nodejs.org/job/node-test-commit/10139/

matthewloring · 2017-05-25T00:59:12Z

I'll plan to land this tomorrow if there are no objections.

addaleax · 2017-05-25T16:26:54Z

Landed in 920278b, thanks a lot for all the work here!

This change provides unified tracking of asynchronous promise lifecycles for both domains and async hooks. PR-URL: #13000 Reviewed-By: Andreas Madsen <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>

Fishrock123 · 2017-05-25T16:39:54Z

I still think if this returns the Promise as the resource that is probably the wrong behavior due to what had been discussed?

This change provides unified tracking of asynchronous promise lifecycles for both domains and async hooks. PR-URL: #13000 Reviewed-By: Andreas Madsen <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>

async_wrap,src: promise hook integration

ef35de1

This change provides unified tracking of asynchronous promise lifecycles for both domains and async hooks.

matthewloring requested review from trevnorris, AndreasMadsen and addaleax May 12, 2017 17:52

nodejs-github-bot added async_wrap c++ Issues and PRs that require attention from people who are familiar with C++. labels May 12, 2017

addaleax added dont-land-on-v4.x labels May 12, 2017

matthewloring mentioned this pull request May 12, 2017

[async_hooks] tracking issue nodejs/diagnostics#29

Closed

27 tasks

AndreasMadsen reviewed May 12, 2017

View reviewed changes

addaleax reviewed May 12, 2017

View reviewed changes

AndreasMadsen reviewed May 12, 2017

View reviewed changes

Matt Loring added 2 commits May 15, 2017 13:48

Reintroduce promise hook sharing

563c1b0

Cleanup

4aaadc0

matthewloring commented May 15, 2017

View reviewed changes

addaleax reviewed May 18, 2017

View reviewed changes

trevnorris previously requested changes May 19, 2017

View reviewed changes

addaleax mentioned this pull request May 21, 2017

Questions: will nodejs expose SetPromiseHook of V8 as javascript API in the future? #13139

Closed

AndreasMadsen approved these changes May 21, 2017

View reviewed changes

addaleax mentioned this pull request May 21, 2017

async_hooks: implement C++ embedder API #13142

Closed

4 tasks

Clean up comments

70f9675

matthewloring added this to the 8.0.0 milestone May 23, 2017

matthewloring requested a review from ofrobots May 23, 2017 17:58

addaleax approved these changes May 23, 2017

View reviewed changes

addaleax mentioned this pull request May 23, 2017

async_hooks: only set up hooks if used #13177

Closed

2 tasks

Matt Loring added 5 commits May 23, 2017 15:40

Clarify use of additional object to track promise lifespan.

d47e97a

Clarifying comment about destroy hooks in test-promise.js

012171a

Remove redundant domain tracking

4e38bda

Fix lint errors

13313bb

Performance improvements

9b9c310

AndreasMadsen approved these changes May 24, 2017

View reviewed changes

Appease linter

81ff7f6

addaleax closed this May 25, 2017

AndreasMadsen mentioned this pull request May 26, 2017

AsyncWrap nodejs/promises#9

Closed

jasnell mentioned this pull request May 28, 2017

8.0.0 Release Proposal #12220

Closed

AndreasMadsen mentioned this pull request Jun 3, 2017

async_hooks: use parent promise as triggerId in init hook #13367

Closed

4 tasks

matthewloring mentioned this pull request Jun 3, 2017

async_hooks does not currently provide a way to track causality for a PromiseReactionJob #13437

Closed

async_wrap,src: promise hook integration #13000

async_wrap,src: promise hook integration #13000

Conversation

matthewloring commented May 12, 2017 • edited Loading

Checklist

Affected core subsystem(s)

matthewloring commented May 12, 2017

Fishrock123 commented May 12, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AndreasMadsen May 12, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AndreasMadsen May 12, 2017 • edited Loading

Choose a reason for hiding this comment

AndreasMadsen May 12, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gsathya commented May 15, 2017

Choose a reason for hiding this comment

addaleax May 16, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AndreasMadsen May 17, 2017 • edited Loading

Choose a reason for hiding this comment

AndreasMadsen May 17, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joshgav commented May 16, 2017

addaleax left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

trevnorris left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

matthewloring commented May 12, 2017 •

edited

Loading

AndreasMadsen May 12, 2017 •

edited

Loading

AndreasMadsen May 12, 2017 •

edited

Loading

AndreasMadsen May 12, 2017 •

edited

Loading

addaleax May 16, 2017 •

edited

Loading

AndreasMadsen May 17, 2017 •

edited

Loading

AndreasMadsen May 17, 2017 •

edited

Loading

addaleax commented May 21, 2017 •

edited

Loading