-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Editorial: Explicitly track async evaluation order of pending modules #3353
base: main
Are you sure you want to change the base?
Conversation
d600852
to
f96a304
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great, thanks for making this clearer.
As you may have seen in #3356, there's a bug in this machinery. The fix is a one liner so we should fix that bug, and you'll need to rebase this on top of the fix.
4cdd981
to
b1c782e
Compare
PR updated, sorry I forgot about this. For #3353 (comment), I pushed it in a second commit to make it easier to review where I'm using |
The execution order of modules that were waiting on a given async module was based on the order in which their [[AsyncEvaluation]] field was set to *true*. This PR replaces the [[AsyncEvaluation]] boolean with an actual number that keeps track of ordering in each agent. It also adds a note on when it's safe to reset this order to 0, since: - implementations might want to prevent this number from overflowing, and V8 currently has a bug that resets the number to 0 too early - figuring out when it's safe to reset the number might not be trivial, given the complexity of the module algorithms.
d5527c1
to
0789693
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with my comment. This is so much nicer, thanks.
Don't forget to update https://tc39.es/proposal-defer-import-eval/#sec-example-cyclic-module-record-graphs-deferred-imports after this lands.
</td> | ||
<td> | ||
a Boolean | ||
~unset~, an integer, or ~done~ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
~unset~, an integer, or ~done~ | |
an integer, ~unset~, or ~done~ |
(editorial convention says to put types before constants)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually did this on purpose, since the value "evolves" from unset, to an integer, to done.
React with 👎 if you think I should still change it :)
@@ -27144,7 +27165,8 @@ <h1> | |||
1. Let _requiredModule_ be the last element of _stack_. | |||
1. Remove the last element of _stack_. | |||
1. Assert: _requiredModule_ is a Cyclic Module Record. | |||
1. If _requiredModule_.[[AsyncEvaluation]] is *false*, set _requiredModule_.[[Status]] to ~evaluated~. | |||
1. Assert: _requiredModule_.[[AsyncEvaluationOrder]] is either ~unset~ or an integer. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
1. Assert: _requiredModule_.[[AsyncEvaluationOrder]] is either ~unset~ or an integer. | |
1. Assert: _requiredModule_.[[AsyncEvaluationOrder]] is either an integer or ~unset~. |
The execution order of modules that were waiting on a given async module was based on the order in which their [[AsyncEvaluation]] field was set to true.
This PR replaces the [[AsyncEvaluation]] boolean with an actual number that keeps track of ordering in each agent. It also adds a note on when it's safe to reset this order to 0, since:
You can verify the numbers in the updated tables for the example using https://nicolo-ribaudo.github.io/es-module-evaluation/.
Fixes #3289