AsyncWrap

[petkaantonov]

Native promises don't have hooks in V8 so interop with AsyncWrap is non-trivial.

• Should it block the PR?
• Should it block unflagging?
• Should it be hacked in, patched in v8 or making our own floating patch etc?

@trevnorris

[chrisdickinson]

From prior discussions the direction we were heading with this was:

• It does not block the PR from landing, but from being unflagged.
• It blocks AsyncWrap from being exposed (since native Promises anywhere in a dep tree break AsyncWrap).
• We would try to expose the microtaskqueue to Node so that we can instrument it properly. This should land upstream in V8, and Node would float the patch.

/cc'ing @ofrobots as well, as I've pinged him to take a look at the proposed approach.

I'm labeling this as "blocks unflagging" for now, but will change it if folks object.

[benjamingr]

👍 @chrisdickinson this sounds reasonable.

[trevnorris]

It blocks AsyncWrap from being exposed

Is this to say that making AsyncWrap public API is blocked because we don't have the API available to make it work correctly with the MicrotaskQueue?

[chrisdickinson]

@trevnorris That was my understanding, yes — since a public AsyncWrap API user wouldn't be able to rely on the ability to back-associate asynchronous events in the presence of native Promise use in their extended dependency chain without modifications to the microtask queue — Object.observe would also break AsyncWrap's contract because of the MicrotaskQueue.

[trevnorris]

@chrisdickinson I'd never planned on holding off making AsyncWrap public on points we can't control. With the work you and others have done to fix this there may be a solution in the near to mid term, but unlike timers and nextTick (which are also not currently supported but on me to implement) there isn't a directly supported API I can use.

This being said, it's not like AsyncWrap would go public tomorrow, or even next month, but I have a feeling that there will always be something in the pipe that won't work properly with AsyncWrap. (e.g. if ever those strange Promise based streams in muddy black magic come to node)

[chrisdickinson]

@trevnorris Understandable. Would it be fair to say that ideally we'd have a resolution for MicrotaskQueue control before exposing AsyncWrap? (Notably: having a solution for the microtask queue would solve the problem of WHATWG streams as well, since those are based on top of Promises.)

[omsmith]

Just as an FYI, I've a PR open against AndreasMadsen's "async-hook" wrapper for a Promise patch (AndreasMadsen/async-hook#2). It's obviously incredibly lacking, but was how I attempted to tackle it with what's available.

Very cool to see the microtask work happening.

[vkurchatkin]

@chrisdickinson custom microtask queue wouldn't be enough if we want to capture context on then call.

[trevnorris]

@chrisdickinson

Would it be fair to say that ideally we'd have a resolution for MicrotaskQueue control before exposing AsyncWrap?

That would be ideal, and would also address the core API gap of queue'ing native callbacks in a nextTick way (i.e. void EnqueueMicrotask(MicrotaskCallback microtask, void* data = NULL);).

Aside on this note, how would AsyncWrap work with the MicrotaskQueue executor from the native side? I believe some enhancements will need to be placed in AsyncWrap, and am will to work that out once this moves forward.

[chrisdickinson]

@vkurchatkin At this point I'm not sure we must do that. .then handlers added synchronously to Node Promise API calls should automatically run in the parent's domain:

d = domain.create()
d.run(() => {
  return fs.readFilePromise()
}).then(data => {
  // runs in d, readFilePromise's executor was run in d, queued `readFile` in d, microtask
  // enqueued by callback of `readFile`
  return fs.existsPromise() // executor + callback are bound to d, resolution runs in d
    .then(() => {
      // still bound to d, since the microtask is queued inside of `existsPromise`
    })
}).then(otherData => {
  // runs in d, since resolution of dependent promise of `existsPromise` is
  // run in d and enqueues microtask there
})

// escapes:
const p = d.run(() => {
  return fs.readFilePromise()
})

setTimeout(() => {
  p.then(() => {
    // not run in d; microtask enqueued by "p.then"
  })
}, 500)

Only handlers added after the resolution of a Node core-returned Promise would pick up the domain of their enclosing scope. While this is probably going to be a bit difficult to document, I believe it should be workable behavior.

[AndreasMadsen]

/cc @nodejs/tracing as I completely missed this myself.

[gsathya]

@trevnorris, Can I get some feedback on this https://bugs.chromium.org/p/v8/issues/detail?id=4643#c12? Thanks!