Consider using WebAssembly JavaScript Promise Integration API (JSPI) for sync-over-async scenarios

[SteveSandersonMS]

Today, .NET on WebAssembly is unable to implement clean support for cases where .NET APIs need to be synchronous, but they can only be implemented asynchronously inside a browser. Examples:

• Cryptography APIs
• Assembly loading (e.g., for lazy loading), where the assembly content must be fetched from the network

An upcoming standard should give us the option to solve these problems: https://v8.dev/blog/jspi, a.k.a. JSPI

JSPI works simply by suspending the WebAssembly runtime until a JS promise completes. Clearly this has the drawback that a UI would be frozen for this period, but that's no different from (say) a Windows Forms UI being suspended for the microseconds needed for a cryptography operation. In the case of lazy-loading an assembly there's more risk that the UI freeze could last for a human-noticeable delay, but presumably the developer could be given some JS-side callback where they can do whatever they want (such as showing a "please wait" UI).

This doesn't invalidate the need for multithreading, but gives us an escape hatch in the case of .NET synchronous APIs that we want to carry over into browsers because in a lot of cases they would work out fine.

cc @dotnet/aspnet-blazor-eng

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Today, .NET on WebAssembly is unable to implement clean support for cases where .NET APIs need to be synchronous, but they can only be implemented asynchronously inside a browser. Examples:

• Crypto APIs
• Assembly loading (e.g., for lazy loading), where the assembly content must be fetched from the network

An upcoming standard should give us the option to solve these problems: https://v8.dev/blog/jspi, a.k.a. JSPI

JSPI works simply by suspending the WebAssembly runtime until a JS promise completes. Clearly this has the drawback that a UI would be frozen for this period, but that's no different from (say) a Windows Forms UI being suspended for the microseconds needed for a crypto operation. In the case of lazy-loading an assembly there's more risk that the UI freeze could last for a human-noticeable delay, but presumably the developer could be given some JS-side callback where they can do whatever they want (such as showing a "please wait" UI).

This doesn't invalidate the need for multithreading, but gives us an escape hatch in the case of .NET synchronous APIs that we want to carry over into browsers because in a lot of cases they would work out fine.

cc @dotnet/aspnet-blazor-eng

Author:	SteveSandersonMS
Assignees:	-
Labels:	arch-wasm, untriaged
Milestone:	-

[lewing]

This is definitely an interesting area and I think is similar to how Wasi is approaching things. I'm marking it as Future just to indicate there are no specific deliverables in net8.0 not that we won't consider it in that time frame

[pavelsavara]

If we are willing to block UI for duration of the DLL download, we could implement it via deprecated synchronous XMLHttpRequest

But I think that if we use JSPI and emscripten ASYNCIFY=2 it would not block the UI. I'm not sure if JSPI could be used without asyncify.

In multi-threading both those scenarios are solvable with more grace.

[SteveSandersonMS]

If we are willing to block UI for duration of the DLL download,

That could mean two different things:

1. Blocking the browser's UI event loop: we are definitely not willing to do that
2. Pausing execution of the .NET code: we are willing to do that

Hopefully this clarifies why synchronous XMLHttpRequest isn't a valid solution whereas JSPI could be.