1616828 - Support top-level await in eager evaluation

Status: RESOLVED WONTFIX

(DevTools :: Console, enhancement, P4)

Description

[Oriol Brufau [:Oriol]]

Type this in the console:

await 1;

Expected: eager evaluation displays 1

Actual: no eager evaluation

Comment 1

[Nicolas Chevobbe [:nchevobbe]]

we'll have to figure out what to do when we're awaiting more than X ms
maybe we could have the result saying <pending> or something, until we get the results, but that would require some changes

that's also something we want to have for evaluated await expressions

Comment 2

[Logan Smyth [:loganfsmyth]]

I'm not sure I'd expect this to ever be realistically supported. Needing to persist eager evaluation state across async boundaries would get really complicated really fast.

Issues that come to mind:

• If tasks spawn other tasks that spawn other tasks and so on, what is responsible for calculating the total runtime of those tasks to eventually make them time out?
• What is responsible for recognizing that the code has terminated and reporting that back to the debugger? If eager code queues up a job, it's just a normal JS job, there's no metadata associated with that job to know that it's meant to be eager, or detect a termination of it or to know where report that back to
• Assuming we eventually want tosupport opcodes that mutate as long as they mutate objects allocated by the eager code, we'd likely implement that by running the GC before eager eval and then only allowing mutation of objects in the nursery, and if eager code can be async, we'd have to run a full GC every time we transition back to a queued job that is marked for eager eval.

Comment 3

[Nicolas Chevobbe [:nchevobbe]]

I don't think there's a chance we're going to support this, let's close the issue.