Avoid reordering execution of module bodies before top-level await is reached

[littledan]

Let's continue discussion on #44 (comment) here. To summarize, @zenparsing noticed a potential reordering issue in #33 , and @bergus and I were chatting about possible ways to avoid it.

[littledan]

@bergus, What do you see as the problem with draining the job queue between siblings? I see it as a midpoint between inserting additional implicit dependencies and not controlling things at all.

[littledan]

About a "synchronous" Promise.all, as proposed in #44 (comment) , that would seem to go against the spirit of what many expressed in
#43

[domenic]

Can someone summarize the issue? Extracting it from the comment thread is hard, and I'd like to first get on the same page as to whether there's actually an issue.

[bergus]

@domenic: @zenparsing brought the example

// a-1.js
console.log('a-1');

// a-2.js
console.log('a-2');

// a.js
import './a-1.js';
import './a-2.js';
console.log('a');

// b.js
console.log('b');

// main.js
import './a.js';
import './b.js';
console.log('main');

with the current ES semantics this will result in

a-1
a-2
a
b
main

and we of course want to keep this ordering. However if we naively just add Promise.all to await all dependencies, we get to evaluate

const a1 = Promise.resolve()    .then(() => console.log('a-1'));
const a2 = Promise.resolve()    .then(() => console.log('a-2'));
const a  = Promise.all([a1, a2]).then(() => console.log('a'));
const b  = Promise.resolve()    .then(() => console.log('b'));
           Promise.all([a, b])  .then(() => console.log('main'));

and the ordering will become

a-1
a-2
b
a
main

which is undesirable.

[littledan]

Right, @bergus summarizes it well. To sum it up, the microtask queue may get gummed up just working through all the microtasks from module evaluation itself, leading a mid-level module in a heavier subtree on the "left" side have its body evaluated after a lighter "right" subtree, even in the absence of top-level await.

[domenic]

Thanks.

I'm not sure this is a problem in HTML, because every script evaluation (including module scripts) there is done by wrapping it in various things, the end of which will run a microtask checkpoint if the stack is empty (which it would be in this case, I believe). Concretely, https://html.spec.whatwg.org/multipage/webappapis.html#run-a-module-script step 9.

Note that there are a lot of important setup and teardown steps there; in general it's important for any synchronous block of code to be run via the host so that the host can maintain its invariants in these sorts of ways.

So as long as we respect that existing infrastructure, this will not be an issue in the browser. I haven't checked if any of the various spec PRs open do or do not respect the existing infrastructure.

[domenic]

Note that this is also taken care of if all script work is queued via EnqueueJob(); see https://html.spec.whatwg.org/multipage/webappapis.html#enqueuejob(queuename,-job,-arguments) step 7.8. So e.g. if you queued separate evaluation jobs for a and then b, the queue would be completely emptied by the time the b job came around, and thus presumably 'a' would have been logged to the console.

[bergus]

@littledan I just think it would be ugly when the module loading component would take control over the job queues, this doesn't look sound from an architectural point of view. But it's not my decision, you would have to discuss this with the TC editors.

@domenic Ah, good point that the HTML spec could solve this, but I'd rather have this behaviour mapped out in the ES spec alone, not relying on the host to run the job queue in the expected order.
However I don't understand what you mean by queuing script work via EnqueueJob. Script evaluation should not be a promise job, should it? And even if it was, those jobs are put on the microtask queue, and the "script clean up" step of the first de-queued job would then perform a microtask checkpoint which would run all the other jobs in the microtask queue - afaics not really a difference wrt. evaluation order from not doing cleanup and just continuing the dequeuing.

I'd rather see the weakly-deterministic-with-yielding strategy from your Determinism vs ASAP document, with dynamic import() featuring the same role as the opt-in second entry point for concurrent evaluation.

[littledan]

@domenic If there's a way that we can handle this logic via HTML, that could be a good solution. I don't understand how the current HTML spec handles this, however.

Step 7.2 of the "run a module script" algorithm notes, the Evaluate algorithm "will recursively evaluate all of the module's dependencies." It's exactly this recursive evaluation that we might need to intersperse microtask queue checkpoints into, but I don't see where the recursion in the ES spec jumps back to this HTML algorithm.

I'm not sure what you're suggesting by EnqueueJob. The only jobs for module evaluation in #33 are Promise reaction jobs due to waiting on dependencies. This hits the HTML EnqueueJob algorithm, but I don't see how that leads to the ordering we want. Is there some other way we should enqueue additional jobs to get another ordering?

[domenic]

Step 7.2 of the "run a module script" algorithm notes, the Evaluate algorithm "will recursively evaluate all of the module's dependencies." It's exactly this recursive evaluation that we might need to intersperse microtask queue checkpoints into, but I don't see where the recursion in the ES spec jumps back to this HTML algorithm.

Currently, Evaluate() only executes one big sync chunk of code. Every sync chunk of code needs to be wrapped in setup/cleanup steps, so in the current setup, nothing more is needed.

What I was alluding to above, was that if whatever changes the top-level await proposal makes also respect this invariant---that every sync chunk of code gets wrapped in a setup/cleanup pair---then I think everything will work as expected.

Similarly, I was pointing out that if sync chunks of code are executed by using EnqueueJob, then you'd get this wrapping for free.

Does this help?

I might still be missing something, as I haven't immersed myself in the problem fully like you have. I am just pattern matching: we need to run microtask checkpoints after each chunk, and HTML has well-established mechanisms for ensuring microtask checkpoints are run. I'm not sure if it solves the problem fully, but I was hopeful. Thus, for example:

if you queued separate evaluation jobs for a and then b, the queue would be completely emptied by the time the b job came around, and thus presumably 'a' would have been logged to the console.

I'm not sure how that lines up with #33, having not reviewed it in detail.

[littledan]

@domenic I see; this is an interesting frame. Maybe there's some way that we could give HTML a chance to clean up after launching a module load. My first shot at HTML integration with top-level await doesn't do that, but I'll think about host hooks that we might add for that purpose.

At the same time, given comments people are making elsewhere about job queue related topics, I imagine there would be interest in ensuring a cross-environment guarantee that this reordering doesn't occur.

Another solution to this problem is to not yield to the job queue when importing a module that does not have a top-level await, as I was suggesting in #43. I think that'd solve this problem as well.