3 ms·
Not sure which spec the article is referring to but it's not the one implemented by V8 natively. > The problem is that Promises have to be resolved in the next
by jkrems 9y ago
Not sure which spec the article is referring to but it's not the one implemented by V8 natively.
> The problem is that Promises have to be resolved in the next turn of the event loop. This is part of the spec.
That statement is false unless I'm missing something major here. Promises aren't resolved in the next turn of the event loop. They should be resolved as part of the microtask queue which can happen at the end of the tick (recursively).
Example (tested on node 8):
Promise.resolve()
.then(() => console.log('1'))
.then(() => console.log('2'))
.then(() => console.log('still the same tick!'));
setTimeout(() => console.log('timeout happening in the next tick'), 0);
Result:
1
2
still the same tick!
timeout happening in the next tick
The same will happen with async functions:
(async () => {
console.log(await Promise.resolve('1'));
console.log(await Promise.resolve('2'));
console.log(await Promise.resolve('still the same tick!'));
})();
setTimeout(() => console.log('timeout happening in the next tick'), 0);
- noonat 9y agoYou're correct. The spec only specifies that "onFulfilled or onRejected must not be called until the execution context stack contains only platform code." This doesn't require that the implementation use the same macro-task scheduling mechanism that setTimeout might use.