Blazor Server unresponsive/unusable when background thread doing work

[Webreaper]

Describe the bug

A Blazor server app that pushes work out to a background thread becomes unresponsive to the point of being unusable, but it doesn't appear to be clear why that would be.

To Reproduce

1. Create a brand new Blazor Server app using the standard template.
2. In Counter.razor, change the IncrementCount handler so to the following implementation:

   private void IncrementCount()
    {
        var metathread = new Thread(new ThreadStart(() => { DoWork(); }));
        metathread.Name = "WorkThread";
        metathread.IsBackground = true;
        metathread.Priority = ThreadPriority.Lowest;
        metathread.Start();
    }

    private void DoWork()
    {
        // Loop through 200 iterations of 'work'
        int count = 0;
        while (count++ < 200)
        {
            // Yield briefly for each iteration...
            Thread.Sleep(100);

            // then work hard (tight loop) for 2 seconds
            var end = DateTime.Now + TimeSpan.FromSeconds(2);
            while (DateTime.Now < end) ;
        }
    }

3. Run the app. If you go to the counter page, click the button, and then click around the app, you'll see a short delay of up to 2s on each UI interaction. If you remove the Thread.Sleep call to simulate constant background processing, the entire GUI basically hangs permanently.

It seems non-obvious as to why this should be; a low priority background thread should not kill the GUI; the UI dispatcher should presumably pre-emptively take precedence.

This problem basically means that you cannot execute any long-running (or even short-running) processing in a background thread in a Blazor Server app, without completely killing the performance of the application and making it effectively unusable.

Further technical details

• Visual Studio for Mac v8.6 build 4274
• ASP.NET Core version: 3.1
• Output of dotnet --info:

.NET Core SDK (reflecting any global.json):
 Version:   3.1.200
 Commit:    c5123d973b

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.15
 OS Platform: Darwin
 RID:         osx.10.15-x64
 Base Path:   /usr/local/share/dotnet/sdk/3.1.200/

Host (useful for support):
  Version: 3.1.2
  Commit:  916b5cba26

.NET Core SDKs installed:
  3.1.200 [/usr/local/share/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.App 3.1.2 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.17 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.2 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

[davidfowl]

It seems non-obvious as to why this should be; a low priority background thread should not kill the GUI; the UI dispatcher should presumably pre-emptively take precedence.

The OS owns pre-emption, not the framework.

This problem basically means that you cannot execute any long-running (or even short-running) processing in a background thread in a Blazor Server app, without completely killing the performance of the application and making it effectively unusable.

CPU bound work you mean? How many concurrent users before this happens? How many CPUs does your machine have?

[Webreaper]

The OS owns pre-emption, not the framework.

Of course. But my point is that I've been writing multi-threaded C# UI apps for decades, and never seen a case where marshaling a bit of work onto a background thread massively blocks/degrades the UI in the same way as is happening with blazor server. So it feels like something odd is happening with the .Net dispatcher.

CPU bound work you mean? How many concurrent users before this happens? How many CPUs does your machine have?

My machine is a brand new i5 2020 Macbook air, so 4 cores. The app has a single user - the problem is easily reproducible just by spinning up the example as written in my first post, within VS for Mac, on a single machine. I also see the same behaviour running on a 4-core linux host.

My understanding from the way preemptive threading is supposed to work is that if you execute work on a low priority background thread, the UI thread should take precedence and preempt if required (eg when a request comes in that needs to be serviced, etc). So I'd expect background low priority threads to not affect the responsiveness of the dispatcher in a Blazor/ASP.Net app - assuming that the background thread is not blocking/locking any resources that are needed by the dispatcher thread. The behaviour I'm seeing makes me wonder if the Blazor dispatcher is running at a low priority or something like that?

[davidfowl]

I can't reproduce this, how many threads did you spin up?

PS: I have 8 CPUs

[Webreaper]

I can't reproduce this, how many threads did you spin up?

The app I'm actually writing spins up 2-3 additional background threads (it's an image management app and it's generating thumbnails and scanning metadata in the background). But it's reproducible with just a single thread in the sample I posted above.

PS: I have 8 CPUs

No need to boast. ;-) That'll probably explain why you can't repro it though - I guess each thread is getting its own CPU, so there's no contention? Perhaps the behaviour is different with a single multi-core CPU. Do we know what the thread priority of the ASP.Net/SignalR dispatcher is? I wonder if there's any way to adjust it.

I wonder if this is just an indication that Blazor/ASP.Net isn't really designed to run on a single-CPU host. Of course, I could farm out the additional thread work to a separate process, but that seems sub-optimal and will massively complicate things. :)

[captainsafia]

@Webreaper Similarly, I'm unable to repro the problem on a few different configurations with various amounts of threads.

Blazor Server does support background threads in the fashion that you described above. Perhaps there's something else in your image manipulation application that is causing the issue? Performance degradation on a Blazor server app with a single background thread and a single user seems strange.

Can you share a repro project via GitHub in case there is something else affecting this that isn't outlined in your repro steps above?

Assuming this repros, I don't think there's anything we can do within Blazor to address this.

[Webreaper]

Okay, sample here: https://github.com/Webreaper/BlazorThreadSample

This is a standard Blazor Server app created from the template. As mentioned in the original bug report, all I've changed is to add a new checkbox - when checked it will spawn a low-priority background thread, which does 10s of work before exiting. The behaviour is as follows:

• Go to the counter page, click the counter button several times in quick succession. The counter increments as expected, with each click.
• Now check the 'enable thread' checkbox, and click the button several times in quick succession. This time you won't see the counter number increment for 10 seconds, and the next few clicks won't be detected by the application at all. After 10 seconds, you can click the button again, and the app will freeze for another 10 seconds.

I see this on my 2020 MacBook Air i5. I've included an animation/video of the effect in the readme.

[captainsafia]

Unfortunately, I'm still not able to repro. I don't think there's anything actionable to do on the Blazor side here.

I'll move this to discussions for the time being to allow space to dig into this issue but I don't think there's enough here to convert this to a formal bug/feature.

[akbettingsystem]

I m having a similar case, where the ui freezes although the long running task is running on a new Thread!

[Webreaper]

I haven't seen this issue since .net 5/6; I suspect any outstanding issues you might be having are related to your background task killing the CPU, rather than anything Blazor related.

[akbettingsystem]

That was my initial thought! However i run the same long running code from a different process, and i did not experience the problem.