4 ms·
I expect that will execute sequentially though as opposed to the solution above it.
by d1plo1d 6y ago
I expect that will execute sequentially though as opposed to the solution above it.
- jakear 6y agoNo, the second fetch is spawned before the first awaited. So by the time execution gets deferred both fetches are running.
- kesor 6y agothe execution starts when the function is called - not when "await" is prepended to its result.
- dllthomas 6y agoArguably correct but possibly misleading. The asynchronous portion of the work is enqueued when the function is called, but does not start executing until it's scheduled, which can't happen until the current task ends or is blocked by an await. This is useful, as it means a promise can't settle before you've had a chance to add handlers; otherwise you might sometimes get UnhandledPromiseRejections because of an unavoidable race condition. I said arguably correct because there's nothing stopping the function from doing a portion of the work synchronously, which would mean the work as a whole starts with the function call.
- TheNorthman 6y agoJudging from your comment history, are you perhaps used to writing asynchronous code in Rust? In most languages, `Futures` start executing from when they are spawned. This is opposed to Rust, where they execute when they are `.await`ed.
- deleted 6y ago[deleted]
- d1plo1d 6y agoOk, 3rd edit. The promises are awaited in sequence but since they are both started before the first await they are run in parallel. Your question about Rust futures makes a ton more sense now. This only works because a promise is self-executing / not inert like a Rust Future. Thank you kind stranger! Your async-foo is strong ^_^
- dllthomas 6y agoI don't expect so. IIUC, work to be done for a promise is (typically) placed in the task queue when the promise is created, and will be eligible to start running the next time you get back to the event loop, which is part of what an `await` does.