Promises patch v8

[chrisdickinson]

This is a WIP, intended to open the discussion on how to proceed with a pluggable MicrotaskQueue. My C++ is rusty, and I've probably made mistakes WRT to not implementing the appropriate HandleScopes — please point these out! Also missing is a mechanism for delete-ing the MicrotaskQueue on Isolate exit. This approach extends the split between EnqueueMicrotask(MicrotaskCallback, void*) and EnqueueMicrotask(Local<Function>) from the public Isolate to the private Isolate.

I've included an example commit that shows how Node could consume this API, by placing microtasks into the nextTick queue. Ultimately we may not unify the queues, but we would make use of this API to allow us to use MakeCallback when entering JS from C++ at top-of-event-loop.

[trevnorris]

Probably should explain that using Isolate::CreateParams is necessary, in the comments above. Similar to how every other class that makes use of Isolate::CreateParams.

[bnoordhuis]

Why not leave this DCHECK in place and drop the abort() call?

[chrisdickinson]

Good point! Will fix.

[ofrobots]

I am worried that a pluggable MicrotaskQueue might be a significant API burden that JS VMs might not want to expose in this manner.

Once VMs implement async/await, keeping this functional would be really hard. For async functions, the thing being added to the micro task queue is not a function but rather some implicitly stored VM state. I would expect it to be unlikely that V8 would want to expose such internal continuation state to an embedder.

[chrisdickinson]

@ofrobots Thanks for the feedback! Do you think it would be better handled as a series of Enqueue, Pre, and Post(optional err) hooks?

[chrisdickinson]

(Possibly Enqueue, Pre, and Post would also pass an opaque handle to embedders, so we can associate data with the callback?)

[ofrobots]

@chrisdickinson Yep, that would be better and avoid exposing continuation state.

BTW, Déjà vu. I have seen this API discussed before. The Angular folks were interested in something like this too before they decided to pursue zones w/ TC39. /cc @littledan, @mhevery.

[littledan]

In general, if you want to make a change to V8, then filing a bug in the V8 bug tracker and/or uploading a change to Rietveldt will get our attention faster than making a pull request against Node's checked-out v8 dependency. See https://github.com/v8/v8/wiki/Contributing for more information. Feel free to contact me, or even better, [email protected], if you have any trouble getting started.

I share @ofrobots 's concerns about whether this is the right way to do it. In particular, in this case, while Promises are currently done through JSFunctions, they might be reimplemented as a MicrotaskCallback in the future as a performance optimization. If we do have different kinds of things on the microtask queue that are distinguished from each other, I think we should use some other marker rather than this C++ type.

If we are going to expand what the microtask queue is, then we should have a good understanding of other use cases which are related, and if we can solve several problems at once, or whether we really need a new feature. Some web frameworks are also interested in being able to intercept the same event, of wrapping various microtask operations; it'd be great if we only exposed one way to do it, rather than one for Node and one for the web. /cc @ajklein