Detect Strict Mode

I believe this example would fall under

Granted, this case is a bit different, because, looking at the source code, the script itself loads really quickly, you've just also got an onload event listener in there that does some really hefty logic. I would call this current design buggy, because it prevents the end-user from interacting with anything, and causes those browser prompts asking the end-user to kill it.

A better design would be to:

  1. do an occasional pause during this long-running task, to give the browser a chance to let other things execute for a bit. This will keep the page responsive, and make it so the browser isn't constantly asking the user to kill the page. I noticed in the code that you already figured this out and had such a solution coded up, you just currently have it disabled.
  2. If we assume a later-run script needs access to functions exported from this one, we ought to design this API to facilitate this. There's multiple ways to do this, but @mhofman's solution works fine here, of just having some sort of event exported, that future-running code can listen to know when you're done building the thesaurus, and when other functions you export can be used.

So, yes, it's certainly possible to make long-running stuff happens when a script loads, or during an on-load event, but I wouldn't call this a "use-case" since it makes for an extremely poor user-experience, and can be circumvented by breaking up the long-running task.

I think you misunderstood. This is a case of code continuing to execute on a page after a script has been preempted (a non-catchable error). Execution resumes after preemption at least: when the dev console triggers code, when an animation frame / interval / timeout lands, when the user interacts with an element that triggers code, when a script that began downloading prior to preemption finishes post-preemption, and maybe under other circumstances. Non-spec behaviors are hard to experiment with.

Also, it's not "buggy", from the readme:

modified as a browser load-test ... to render the page unresponsive during initialization. User agents will react differently, including potentially: Asking the user to stop the script or triggering an out-of-memory error.

(To get the "normal" behavior, with a load bar, you would set USE_LOOP = true in the source; I disabled it specifically to create this preemption example.)

Yeah this is definitely problematic in the sense that it would leave code in an inconsistent state.

For reference, there is problem today with OOM errors. While these are catchable, they leave the program in an inconsistent state if caught. We would like these errors to be potentially uncatchable: GitHub - tc39/proposal-oom-fails-fast: Proposal: Out of memory immediately terminates agent cluster

No host would then be allowed to perform any further execution inside the agent that failed this way.

I would say that unfortunately what to do in these cases has been left unspecified, which leads to these problematic cases. Thankfully all these example are web host integration caused. I wouldn't be surprised however if a simple host callback from the 262 spec may not also be allowed to continue execution, for example a finalization registry callback.

Anyway, thanks for the report, we knew the current state was bad, but I didn't realize even "uncatchable preemptions" are also botched.

When you say "this is a case", do you mean "use-case", as in, "this is useful behavior that someone may want to do with public-facing software", in which case, I would lean on my arguments above, stating that, no, this behavior makes for an extremely bad experience for the end-user, and it can be circumvented by inserting pauses into the execution of the long-running task, and I would call this behavior "buggy" the same way I would call a program buggy if one of its many processes would sometimes crash with a null-pointer exception - even if that crash was documented in the README I would still consider it to be buggy.

Or, does "this is a case" mean "it's possible to make this happen", in which case, yes, absolutely, this webpage definitely proves that bad scripts can be killed part-way through and yet the page can still be interacted with afterward. And, your README does state it's a "browser load-test", i.e. you're purposely trying to make a bad user experience just to see how the platform behaves, in which case, no, it's not buggy, because it's a special program that's doing its job of showcasing how browsers behave when given a long-running task that doesn't pause.

Just realizing that @mhofman was saying earlier that they would be interested in knowing more about the behavior of pre-emption mechanism, and then you replied with this example.

So, "this is a case" probably meant "here's an example for you @mhofman".

And I got myself all confused.

By the way, animation frames also survive page kills / reloads (and continue logging to the console). They interact with an outdated global context so they wont affect the context of a reloaded page and they can't keep re-scheduling themselves for long, but they can continue posting messages to workers and servers.