[wasm-mt] Add a System.Runtime.InteropServices.JavaScript.BrowserSynchronizationContext

[lambdageek]

Update this is no longer a public API proposal. instead, we should make an internal SynchronizationContext subclass that is installed by the runtime on the main thread.

---

Background and motivation

In order to enable multi-threaded WebAssembly programming, we want to allow users to continue to program using async/await. In the current single-threaded browser-wasm runtime, all asynchronous tasks run on the main browser thread implicitly as there is nowhere else to run them. Our multi-threaded WebAssembly programming model is built on WebWorkers - dedicated threads that do not share system memory with the main browser thread but may pass messages to it back and forth including WebAssembly main memory using a SharedArrayBuffer.

In multi-threaded WebAssembly, certain operations (for example code that manipulates the DOM of the current page) must run on the browser's main event loop, not in a WebWorker. As a result, it is necessary to add a SynchronizationContext subclass that allows asynchronous work to be posted back to the main browser thread.

API Proposal

using System.Threading;

namespace System.Runtime.InteropServices.JavaScript;

/// A synchronization context that queues work to run on the browser's main thread.
/// In a multi-threaded web application certain operations (such as manipulating the DOM) must be done on the
/// main thread and not in a WebWorker.  The BrowserSynchronizationContext allows asynchronous callbacks to
/// return to run their continuations on the main thread.
[SupportedOSPlatform("browser")]
internal sealed class BrowserSynchronizationContext : SynchronizationContext
{
    internal BrowserSynchronizationContext();
    public override SynchronizatonContext CreateCopy();
    public override void Post(SendOrPostCallback d, object state);
    //// Always throws NotSupportedException
    public override void Send(SendOrPostCallback d, object state);
}

API Usage

In a .razor page in Blazor:

<button @onclick="DoSomeWork">Start Work</button>
<text>Result is: @output</text>

@code {
    string output = "";
    public async Task DoSomeWork() {
        output = "pending";
        Debug.Assert (SynchronizationContext.Current instanceof BrowserSynchronizationContext);
        var result = await Task.Run(Model.SomeAsyncWork); // start some work on the threadpool
        output = result.ToString();  // return to the UI thread and update the model
    }
}

Alternative Designs

1. We could create some kind of JavaScript shim that exposes proxy objects for manipulating the DOM from an arbitrary webworker and leave the C# layer oblivious. (We would have to do this for every JS API that is only available in the main browser thread)
2. We could add a synchronization context class for posting work to arbitrary web workers' event loops. In that case the main thread would not be special:

       public class JSEventLoopSynchronizationContext : SynchronizationContext {
           public JSEventLoopSynchronizationContext (Thread t);
           public static JSEventLoopSynchronizationContext Browser;
           // same overrides as before
       }

We can also consider some other names:

• some other namespace
• DOMSynchronizationContext
• MainEventLoopSynchronizationContext
• JavaScriptSynchronizationContext

Other considerations:

• the eventloop, tasks and microtasks are not a browser concept, they're a JS concept. So we may want a name that makes sense in Node environments, too.

Risks

No response

[lambdageek]

/cc @lewing @kg

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

Issue Details

---

Background and motivation

In order to enable multi-threaded WebAssembly programming, we want to allow users to continue to program using async/await. In the current single-threaded browser-wasm runtime, all asynchronous tasks run on the main browser thread implicitly as there is nowhere else to run them. Our multi-threaded WebAssembly programming model is built on WebWorkers - dedicated threads that do not share system memory with the main browser thread but may pass messages to it back and forth including WebAssembly main memory using a SharedArrayBuffer.

In multi-threaded WebAssembly, certain operations (for example code that manipulates the DOM of the current page) must run on the browser's main event loop, not in a WebWorker. As a result, it is necessary to add a SynchronizationContext subclass that allows asynchronous work to be posted back to the main browser thread.

API Proposal

using System.Threading;

namespace System.Runtime.InteropServices.JavaScript;

/// A synchronization context that queues work to run on the browser's main thread.
/// In a multi-threaded web application certain operations (such as manipulating the DOM) must be done on the
/// main thread and not in a WebWorker.  The BrowserSynchronizationContext allows asynchronous callbacks to
/// return to run their continuations on the main thread.
[SupportedOSPlatform("browser")]
public sealed class BrowserSynchronizationContext : SynchronizationContext
{
    public BrowserSynchronizationContext();
    public override SynchronizatonContext CreateCopy();
    public override void Post(SendOrPostCallback d, object state);
    //// Always throws NotSupportedException
    public override void Send(SendOrPostCallback d, object state);
}

API Usage

In a .razor page in Blazor:

<button @onclick="DoSomeWork">Start Work</button>
<text>Result is: @output</text>

@code {
    string output = "";
    public async Task DoSomeWork() {
        output = "pending";
        Debug.Assert (SynchronizationContext.Current instanceof BrowserSynchronizationContext);
        var result = await Task.Run(Model.SomeAsyncWork); // start some work on the threadpool
        output = result.ToString();  // return to the UI thread and update the model
    }
}

Alternative Designs

1. We could create some kind of JavaScript shim that exposes proxy objects for manipulating the DOM from an arbitrary webworker and leave the C# layer oblivious. (We would have to do this for every JS API that is only available in the main browser thread)
2. We could add a synchronization context class for posting work to arbitrary web workers' event loops. In that case the main thread would not be special:

       public class JSEventLoopSynchronizationContext : SynchronizationContext {
           public JSEventLoopSynchronizationContext (Thread t);
           public static JSEventLoopSynchronizationContext Browser;
           // same overrides as before
       }

We can also consider some other names:

• some other namespace
• DOMSynchronizationContext
• MainEventLoopSynchronizationContext
• JavaScriptSynchronizationContext

Other considerations:

• the eventloop, tasks and microtasks are not a browser concept, they're a JS concept. So we may want a name that makes sense in Node environments, too.

Risks

No response

Author:	lambdageek
Assignees:	-
Labels:	api-suggestion, arch-wasm, area-System.Runtime.InteropServices.JavaScript
Milestone:	7.0.0

[stephentoub]

Who installs the synchronization context? I'm wondering if it needs to be public or if it can just be an implementation detail; most of them are the latter.

[lambdageek]

Who installs the synchronization context? I'm wondering if it needs to be public or if it can just be an implementation detail; most of them are the latter.

Oh interesting, I hadn't realized that. I think that's reasonable for the main thread.

I guess if we later decide to add a synchronization context that will post work to any web worker's event loop, that one would probably need to be public (or at least we might want to add some method that takes a Thread and returns a SynchronizationContext somewhere).

---

Going to rewrite this issue to focus on just adding an internal synch context that is installed by the runtime

[radical]

@kg Moving this to 8.0 . Please change it back, if that's incorrect.