This repository was archived by the owner on Mar 31, 2018. It is now read-only.
Repository navigation
This repository was archived by the owner on Mar 31, 2018. It is now read-only.
Async/Await implementation in V8 #4
Description
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
unhandledRejectionmight 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.
Activity
chrisdickinson commentedon Feb 15, 2016
This issue is a bit open-ended. Would you mind scoping it in, or closing it if it can't be scoped in?
petkaantonov commentedon Feb 15, 2016
This is discussed in #8 , (point 2. in OP)
benjamingr commentedon Feb 15, 2016
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.
[-]Async/Await[/-][+]Async/Await implementation in V8[/+]benjamingr commentedon Feb 15, 2016
I changed the name is this better @chrisdickinson ?
chrisdickinson commentedon Feb 15, 2016
Excellent, thank you!
littledan commentedon Feb 16, 2016
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:
petkaantonov commentedon Feb 16, 2016
@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:
chrisdickinson commentedon Feb 16, 2016
@littledan There are two problems with core dumps and promises at present:
rejectAPromise().then(A).then(B).then(C)will catch and rethrow the error three times, and theabortwill happen atC'sPromiseIdRejectHandler, instead at the source of the rejection inrejectAPromiseas desired. @misterdjules has some work put towards this — primarily around running handlers and executors withouttry / catchif a--abort-on-uncaught-exceptionflag is set andPromiseHasUserDefinedRejectHandleris false.unhandledRejectionlistener, 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 patchPromise.rejectto return a pending promise that rejects on next tick instead of immediately.)petkaantonov commentedon Feb 16, 2016
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 commentedon Feb 16, 2016
@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 commentedon Feb 16, 2016
@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,
thisvalue andargumentsand 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 commentedon Feb 21, 2016
@CrabDude any progress? Anything you need help with?
44 remaining items
ofrobots commentedon Oct 25, 2016
That is not a release announcement. 'V8 5.5 has branched and this is what
it contains'
On Tue, Oct 25, 2016 at 5:28 AM Piero notifications@github.com wrote:
chrisveness commentedon Oct 25, 2016
... "will be in beta until it is released in coordination with Chrome 55 Stable in several weeks"
rvagg commentedon Oct 30, 2016
Can you clarify this a little more @ofrobots? I've been working under the assumption that a 5.5 mid-current wouldn't be a big deal, are you thinking that our lack of ability to interact properly with Promise internals should hold that back because of how widely async/await will be adopted?
leodutra commentedon Oct 30, 2016
I have another worry about this. I can't stop thinking how nice would be
each promisse running in a libuv thread. I don't know if it is implemented
this way today, but if the cost of these threads are cheap... Maybe using
stream internally to run the hidden promise resolutions could make node
even more powerful.
It's the point of view of a passing guy, MHO.
ljharb commentedon Oct 30, 2016
@leodutra it would have to be unobservable to the underlying JS to be spec-compliant - JS is single-threaded.
leodutra commentedon Oct 30, 2016
ljharb commentedon Oct 30, 2016
@leodutra that's certainly one opinion. There's quite a number of people, like myself, who consider threading a legacy programming model. None the less, this is the way JS is and will stay.
nickserv commentedon Nov 1, 2016
Also, isn't the async/await implementation still using Promises or something similar internally? If so, Promises have already been stable in V8/Node, so I see less risk in pushing prereleases with async/await support.
adnan-kamili commentedon Dec 2, 2016
Chrome 55 stable is out, @littledan are there any API breaking changes, if no can we expect it to part of next Node.js 7.x release and get rid of harmony flag for async await
billinghamj commentedon Dec 3, 2016
@adnan-kamili The breaking changes would be at the native API level, and there almost certainly are some. Unfortunately this is unlikely before Node v8 :(
ofrobots commentedon Dec 5, 2016
You can track the status of the effort to integrate V8 5.5 here: nodejs/node#9618
billinghamj commentedon Dec 6, 2016
nodejs/node#9618 (comment) - so should be coming to v7 :)
AMorgaut commentedon Dec 21, 2016
@nickmccurdy async functions are also based internally on generators, so they also need them to be stable, not just the Promises. But I think that's the case ;-)
adnan-kamili commentedon Feb 1, 2017
Issue tracking the backport of v8 5.5 into 7.x branch
nodejs/node#11029