4 ms·

I'm not super familiar with javascript, but this would be very surprising to me? The instantiation of the work should be at the issuance of the promise, after w

I'm not super familiar with javascript, but this would be very surprising to me? The instantiation of the work should be at the issuance of the promise, after which it would be in the queue of things to be done next time control is returned to the event loop. `await` should just return control to the event loop (ie. actually transform the remaining code into a callback). If you've issued the two promises before that happens both should be able to start operation. As far as I know the difference here would be effectively (in very loose pseudo-code: fetch(first).then { fetch(second).then { doThings(); }; }; vs. a = fetch(first); b = fetch(second); a.then { b.then { doStuff(); } }; which to my understanding should do both fetches in parallel even though the resolution is not. Looking at a bunch of articles about "how Promise.all can be implemented" it looks like this kind of recursive resolution of the promises is one of the methods that's expected to work (if not perform terribly well in the general case)? See this SO answer for eg. as well: https://stackoverflow.com/a/46348155 https://stackoverflow.com/a/46348155

nine_k 6y ago
May understanding can as well be wrong! I expected `await X` to create the promise `X` when it starts executing, much like `cond_A || cond_B` only computes `cond_B` when `cond_A` has been computed and turned out falsy. Else how the following code ever work correctly? const x = await foo(); const y = await bar(x); We cannot schedule `bar()` before we have computed its inputs. OTOH `(await x()).concat(await y())` could speculatively compute both promises concurrently, even if it does not yet know whether the result of `x()` has a property named `concat`. I won't normally expect it, but JS is used to defy logic in many areas :-\
- stormbrew 6y ago
  no, generally `await` is the fulfilment of a promise already created. `foo()` returns a promise, and then the await triggers the ceding of control to the event loop and allows the promise to progress. In the example you've shown, it is absolutely correct that the two promises must be sequentially awaited like that. The OP is talking about a situation where there is no dependency between x and y.

nine_k 6y ago

May understanding can as well be wrong! I expected `await X` to create the promise `X` when it starts executing, much like `cond_A || cond_B` only computes `cond_B` when `cond_A` has been computed and turned out falsy. Else how the following code ever work correctly? const x = await foo(); const y = await bar(x); We cannot schedule `bar()` before we have computed its inputs. OTOH `(await x()).concat(await y())` could speculatively compute both promises concurrently, even if it does not yet know whether the result of `x()` has a property named `concat`. I won't normally expect it, but JS is used to defy logic in many areas :-\

stormbrew 6y ago
no, generally `await` is the fulfilment of a promise already created. `foo()` returns a promise, and then the await triggers the ceding of control to the event loop and allows the promise to progress. In the example you've shown, it is absolutely correct that the two promises must be sequentially awaited like that. The OP is talking about a situation where there is no dependency between x and y.