Re: Adding support for Top Level Await to Blink

[Kouhei Ueno]

Hi Joshua,

cc: module-dev (PUBLIC LIST)

Sorry for the late reply. Thank you for implementing this!

I think dynamic import support is pretty straightforward, since we can just delay the import() promise resolve.

Do you have any spec pointers on how TLAs should work on <script type=module>s?

If they were not <script type=module async>, should we pause evaluating the following <script>s?

On Tue, Oct 1, 2019 at 1:07 AM Joshua Litt <joshu...@google.com> wrote:

Hello Kouhei,

I am the V8 engineer who added support for Top Level Await to V8. I wanted to sync up, and figure out the path to getting this feature enabled in Blink. The major change from a module loading perspective is that Module::Evaluate now returns a promise, and the module loader must now wait for the resolution of this promise.

In D8, I accomplished this by simply blocking until the module's promise resolves. This was the cl that added support for top level await to D8.  I imagine such a solution will not be possible in Blink.

Anyway, what are your thoughts on the best way to implement support for top level await in Blink?

Thanks,

Joshua Litt

--

kouhei

[Joshua Litt]

Great question! @Myles Borins, do you have an answer as to how TLA should work on <script type=module>?

Currently, V8 with '--harmony-top-level-await' does not distinguish between async and non-async modules. Specifically, Module::Evaluate with the flag always returns a promise, even for non-async modules, the promise is just resolved immediately. We can add a different API if there is a desire to preserve the existing behavior for non-async modules, but it gets tricky when there are nested dependencies which may be async. Thoughts?

[Myles Borins]

My impression was that if a graph has no instances of Top-Level Await then it should continue to have the exact same behavior as we observe today (e.g. first script tag finishes executing before the next script tag begins executing).

If there is a Top-Level await, but no async attribute I think we should enforce the same behavior... based on HTML spec my impression is that script tags that include `type=module` but don't include `async` should preserve the FIFO behavior of scripts. If we want to change that we should likely make a change to the HTML spec.

[Myles Borins]

And of course right after I send the email I get a response that seems to imply my intuition is wrong. There is an unlanded update to the HTML spec for Top-Level await integration that defines the behavior

https://github.com/whatwg/html/pull/4352

[Myles Borins]

More specifically this seems to be where the behavior is defined

https://whatpr.org/html/4352/a387c7b...a5cdc5b/scripting.html#script-processing-model:run-a-module-script

littledan has offered to help if needed. Are we implementing WPT for this?

[Joshua Litt]

friendly ping. Should we rope in littledan to land the necessary spec change? Is that all that is blocking implementation work? Do we have a bug for the blink side changes? I am happy to help out in anyway I can.

[Myles Borins]

Am I blocking anything here?

[Adam Klein]

From my reading of this thread it sounds like there's some spec text available that could answer Kouhei's question at the top of the thread.

Kouhei: Is spec text the only thing blocking you from working on this? It looks like there's a pending PR against the spec (linked by Myles above), which hopefully would answer your questions. Is this something you (or someone on your team) have bandwidth for this quarter?

Myles: when you say "littledan has offered to help if needed", what do you mean exactly? Is this about getting the spec PR landed? As for Web Platform Tests, those normally only come from Blink as part of an implementation, so from my perspective they're likely to block on Kouhei's answers to my questions above.

Thanks,

Adam

--
You received this message because you are subscribed to the Google Groups "module-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to module-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/module-dev/CAD7Fb3e2uYizFAy6Ebpv5%2BkFru3tbAjF%3DreV%2BwDPFF16JhExmg%40mail.gmail.com.

[Kouhei Ueno]

Hi,

On Fri, Oct 25, 2019 at 9:52 AM Adam Klein <ad...@chromium.org> wrote:

From my reading of this thread it sounds like there's some spec text available that could answer Kouhei's question at the top of the thread.

Kouhei: Is spec text the only thing blocking you from working on this? It looks like there's a pending PR against the spec (linked by Myles above), which hopefully would answer your questions. Is this something you (or someone on your team) have bandwidth for this quarter?

I added a minor comment on the PR. I think the spec is good enough to start implementing. We may encounter issues as we implement, but we can always feedback to the spec author once we find something.

I'm currently based of the platform architecture team, and I don't have bandwidth to work on this in my 20% time. I'm happy to review the CLs.

Impl wise: PendingScript::ExecuteScriptBlockInternal [cs] implements the spec steps "execute a script block", so we can start from there.

 

Myles: when you say "littledan has offered to help if needed", what do you mean exactly? Is this about getting the spec PR landed? As for Web Platform Tests, those normally only come from Blink as part of an implementation, so from my perspective they're likely to block on Kouhei's answers to my questions above.

Thanks,

Adam

On Wed, Oct 23, 2019 at 3:33 PM 'Myles Borins' via module-dev <modul...@chromium.org> wrote:

Am I blocking anything here?

On Tue, Oct 22, 2019 at 2:48 PM Joshua Litt <joshu...@google.com> wrote:

friendly ping. Should we rope in littledan to land the necessary spec change? Is that all that is blocking implementation work? Do we have a bug for the blink side changes? I am happy to help out in anyway I can.

On Thu, Oct 3, 2019 at 11:46 AM Myles Borins <myles...@google.com> wrote:

More specifically this seems to be where the behavior is defined

https://whatpr.org/html/4352/a387c7b...a5cdc5b/scripting.html#script-processing-model:run-a-module-script

littledan has offered to help if needed. Are we implementing WPT for this?

On Thu, Oct 3, 2019 at 2:06 PM Myles Borins <myles...@google.com> wrote:

And of course right after I send the email I get a response that seems to imply my intuition is wrong. There is an unlanded update to the HTML spec for Top-Level await integration that defines the behavior

https://github.com/whatwg/html/pull/4352

--
You received this message because you are subscribed to the Google Groups "module-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to module-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/module-dev/CAD7Fb3e2uYizFAy6Ebpv5%2BkFru3tbAjF%3DreV%2BwDPFF16JhExmg%40mail.gmail.com.

--

kouhei

[tynettet...@gmail.com]

My husband Jonathan Leonard tippens and my kids are my everything

[tynettet...@gmail.com]

[Tynette Bullock jay wifey]

Stop sending my wife massage