How does Task.Yield work under the hood in Blazor WebAssembly?

Question 1

How does Task.Yield work under the hood in Mono/WASM runtime (which is used by Blazor WebAssembly)?

To clarify, I believe I have a good understanding of how Task.Yield works in .NET Framework and .NET Core. Mono implementation doesn't look much different, in a nutshell, it comes down to this:

static Task Yield() 
{
    var tcs = new TaskCompletionSource<bool>();
    System.Threading.ThreadPool.QueueUserWorkItem(_ => tcs.TrySetResult(true));
    return tcs.Task;
}

Surprisingly, this works in Blazor WebAssembly, too (try it online):

<label>Tick Count: @tickCount</label><br>

@code 
{
    int tickCount = System.Environment.TickCount;

    protected override void OnAfterRender(bool firstRender)
    {
        if (firstRender) CountAsync();
    }

    static Task Yield() 
    {
        var tcs = new TaskCompletionSource<bool>();
        System.Threading.ThreadPool.QueueUserWorkItem(_ => tcs.TrySetResult(true));
        return tcs.Task;
    }

    async void CountAsync() 
    {
        for (var i = 0; i < 10000; i++) 
        {
            await Yield();
            tickCount = System.Environment.TickCount;
            StateHasChanged();
        }
    }
}

Naturally, it all happens on the same event loop thread in the browser, so I wonder how it works on the lower level.

I suspect, it might be utilizing something like Emscripten's Asyncify, but eventually, does it use some sort of Web Platform API to schedule a continuation callback? And if so, which one exactly (like queueMicrotask, setTimout, Promise.resove().then, etc)?

Updated, I've just discovered that Thread.Sleep is implemented as well and it actually blocks the event loop thread

.net async-await blazor c#

2021-11-24 06:13:47

Question 2

It’s setTimeout. There is considerable indirection between that and QueueUserWorkItem, but this is where it bottoms out.

Most of the WebAssembly-specific machinery can be seen in PR 38029. The WebAssembly implementation of RequestWorkerThread calls a private method named QueueCallback, which is implemented in C code as mono_wasm_queue_tp_cb. This in invokes mono_threads_schedule_background_job, which in turn calls schedule_background_exec, which is implemented in TypeScript as:

export function schedule_background_exec(): void {
    ++pump_count;
    if (typeof globalThis.setTimeout === "function") {
        globalThis.setTimeout(pump_message, 0);
    }
}

The setTimeout callback eventually reaches ThreadPool.Callback, which invokes ThreadPoolWorkQueue.Dispatch.

The rest of it is not specific to Blazor at all, and can be studied by reading the source code of the ThreadPoolWorkQueue class. In short, ThreadPool.QueueUserWorkItem enqueues the callback in a ThreadPoolQueue. Enqueueing calls EnsureThreadRequested, which delegates to RequestWorkerThread, implemented as above. ThreadPoolWorkQueue.Dispatch causes some number of asynchronous tasks to be dequeued and executed; among them, the callback passed to QueueUserWorkItem should eventually appear.

user3840170 · Answer 1 · 2021-11-28T11:17:30

It’s setTimeout. There is considerable indirection between that and QueueUserWorkItem, but this is where it bottoms out.

Most of the WebAssembly-specific machinery can be seen in PR 38029. The WebAssembly implementation of RequestWorkerThread calls a private method named QueueCallback, which is implemented in C code as mono_wasm_queue_tp_cb. This in invokes mono_threads_schedule_background_job, which in turn calls schedule_background_exec, which is implemented in TypeScript as:

export function schedule_background_exec(): void {
    ++pump_count;
    if (typeof globalThis.setTimeout === "function") {
        globalThis.setTimeout(pump_message, 0);
    }
}

The setTimeout callback eventually reaches ThreadPool.Callback, which invokes ThreadPoolWorkQueue.Dispatch.

The rest of it is not specific to Blazor at all, and can be studied by reading the source code of the ThreadPoolWorkQueue class. In short, ThreadPool.QueueUserWorkItem enqueues the callback in a ThreadPoolQueue. Enqueueing calls EnsureThreadRequested, which delegates to RequestWorkerThread, implemented as above. ThreadPoolWorkQueue.Dispatch causes some number of asynchronous tasks to be dequeued and executed; among them, the callback passed to QueueUserWorkItem should eventually appear.

A great answer, tks! But geven it's setTimeout, could you explain a huge discrepancy I'm seeing when timing a loop of await new Promise(r => setTimeout(r, 0)) with JS interop vs a loop of await Task.Yield? Is there a flaw in the test? blazorrepl.telerik.com/QlFFQLPF08dkYRbm30
queueMicrotask (as opposed to setTimeout) produces a much closer result: blazorrepl.telerik.com/QFbFGVFP10NWGSam57
I am unable to open any of the REPL links, so I cannot tell what you mean. But if you study the source code of ThreadPoolWorkQueue.Dispatch, you will notice there is some sophisticated scheduling involved as well, and one setTimeout may serve multiple queued .NET asynchronous tasks, which I would expect to be faster than having each setTimeout dispatch a single callback.
Odd repl links don't work. If you'd still like to try it, here's the gist: gist.github.com/noseratio/73f6cd2fb328387ace2a7761f0b0dadc. It's literrally 8000ms vs 20ms. Then just replace setTimeout with queueMicrotask, and it's about the same 20ms.
Seems like it: setTimeout makes the browser process the event loop in between callbacks, but the .NET runtime can dispatch multiple asynchronous tasks in a single setTimeout callback (dequeuing them almost immediately after they are queued), thus avoiding the overhead of yielding to the event loop. (Also, browsers may perform throttling on setTimeout calls, which this batching avoids.) This produces an effect roughly equivalent to queueMicrotask. Although the timings you get are probably not very accurate, thanks to Spectre mitigations.

How does Task.Yield work under the hood in Blazor WebAssembly?

In other languages

This page is in other languages

Popular in the category