Async/Await implementation in V8

[benjamingr]

Async await is coming our way with v8 slated to implement it in Q2 2016.

Node needs to be prepared :)

Possible areas of impact:

• V8's implementation needs to be tracked so we make sure we have our right hooks when it lands. Things like unhandledRejection might possibly be impacted as well as the way promises are currently queued and run in Node.
• We need to consider the whole operational vs. programmer error issue here.
• Core dumps should work properly in async methods.

Probably many others, just starting the discussion.

[chrisdickinson]

This issue is a bit open-ended. Would you mind scoping it in, or closing it if it can't be scoped in?

[petkaantonov]

Core dumps should work properly in async methods.

This is discussed in #8 , (point 2. in OP)

[benjamingr]

Basically - to track https://bugs.chromium.org/p/v8/issues/detail?id=4483 and make sure we're keeping up with the implementation from the node side and until then to discuss desirable behavior we'd like async functions to have in Node. Namely that none of the hooks (unhandledRejection, rejectionHandled) break.

This is non-blocking for the promises-in-core PR just so we're clear. I'll scope it in.

[benjamingr]

I changed the name is this better @chrisdickinson ?

[chrisdickinson]

Excellent, thank you!

[littledan]

To clarify, V8 intends to implement async/await but we don't have any particular schedule announced. async/await is a lot like using Promises directly. I'm not sure if anything special is needed for Node's needs here. But if there are other requirements, I'd really like to hear about them. About the points here:

• Unhandled rejections will be handled, according to the spec, just like Promise unhandled rejections, and invoke the handlers as appropriate.
• For operational/programmer errors, I like the idea of a convention to either return some kind of error code or passing an error callback as opposed to using Promise rejection within Node. Promise rejection is equivalent to throwing an exception, and async/await makes this very clear, so if exceptions are to be avoided in Node, then error callbacks or codes would work better.
• For core dumps, seems like the important thing is that the unhandled rejection callback can do a core dump. Does anyone know if there are any issues with these callbacks and core dumps at the moment? I don't see async/await changing a lot about them here vs how things are today with Promises.

[petkaantonov]

@littledan

Errors with promise users are always through one channel even in node and any exceptions node tries to throw for promise users can be caught or listened with domains and turned into rejections. This way the consumer decides whether an error is operational/programmer error because the producer of the error simply cannot know this. Adding additional error channel doesn't add value to this as it is the producer who will choose the channel at error production time and therefore the consumer would be forced to duplicate code for the different channels. There are plenty of examples how the same error can be programmer error and operational error depending on what the consumer is doing.

Glossary:

• producer means producer of the error
• consumer means consumer of the error

[chrisdickinson]

@littledan There are two problems with core dumps and promises at present:

1. Unhandled rejection at the end of a chain — that is, rejectAPromise().then(A).then(B).then(C) will catch and rethrow the error three times, and the abort will happen at C's PromiseIdRejectHandler, instead at the source of the rejection in rejectAPromise as desired. @misterdjules has some work put towards this — primarily around running handlers and executors without try / catch if a --abort-on-uncaught-exception flag is set and PromiseHasUserDefinedRejectHandler is false.
2. (This is primarily on the Node end, but!) Right now we wait until the end of the microtask queue to fire the unhandledRejection listener, so that we can check that the promises rejected during microtask execution have not been synchronously handled. This means that we have to unwind the stack, which produces less useful cores. We may be able to switch our behavior using flags here, but it means all synchronous rejections will immediately abort the program (i.e., we may have to patch Promise.reject to return a pending promise that rejects on next tick instead of immediately.)

[petkaantonov]

The stack can be saved and restored later like. Chrome has to do something like this for the async debugger to work. Theoretically the mutable objects that a stack points to might have been destructively changed but there is a high chance this isn't a practical concern.

[benjamingr]

@littledan like @petkaantonov and @chrisdickinson said - any help with porting the async stack traces like functionality to node that would allow us to save and restore the stack for inspection would be greatly appreciated.

Clarification: The feature in Chrome is called async stack traces but it actually saves the actual stack and not just the trace.

[benjamingr]

@CrabDude Awesome. That would be great!

I think the first step is to figure out and map how Chrome's async stack traces feature works - how we can keep track of the stack, this value and arguments and how things work.

This post contains the PRs node-inspector/node-inspector#340

The challenging part isn't just getting the trace - it's getting the stack frame - in the devtools I can access the closure variables, this value and more. If we can produce and then consume similar output that would be awesome for debugging.

Here is an HTML5Rocks article about how to use the feature in case you are not already familiar http://www.html5rocks.com/en/tutorials/developertools/async-call-stack/

[benjamingr]

@CrabDude any progress? Anything you need help with?