My reactive code (invlolving Throttle and WhenAnyValue) is Deadlocking

[andreas-foreflight]

Hello,

I have been using ReactiveUI with Blazor for a while now and run into the following issue. I have tried to make this example as small as possible. As you might be able to tell from the title, I am not really sure what exactly is causing the issue, so I am also not sure if this example is truly minimal.

View model:

public class DeadlockTestViewModel : ReactiveObject
{
    private readonly ObservableAsPropertyHelper<string> m_observ;
    public string Observ => m_observ.Value;

    private string m_start = "";
    public string Start
    {
        get => m_start;
        set => this.RaiseAndSetIfChanged(ref m_start, value);
    }

    public DeadlockTestViewModel()
    {
        var inputObservable = this.WhenAnyValue(t => t.Start)
            .Throttle(TimeSpan.FromMilliseconds(200));

        var output = inputObservable
            .Select(a =>
                Observable.Start(() => "imagine this string could take a while to calculate")
                    .StartWith("a new value is being calculated")
            )
            .Switch()
            .StartWith("Nothing has been done yet");

        m_observ = output.ToProperty(this, t => t.Observ);
    }
}

blazor view:

@inherits ReactiveComponentBase<DeadlockTestViewModel>

@using ReactiveUI.Blazor
@using MyProject.ViewModels

@page "/deadlock"

@if (ViewModel != null)
{
    <input id="start"
           type="text"
           class="form-control"
           placeholder="START"
    @bind-value="ViewModel!.Start"
    @bind-value:event="oninput" />

    <p>@ViewModel.Start</p>

    <p>@ViewModel.Observ</p>
}

@code {
    [Parameter]
    public string? Direct { get; set; }

    [Inject]
    public DeadlockTestViewModel? DirectViewModel
    {
        get => ViewModel;
        set => ViewModel = value;
    }
}

And this is what tends happens when I interact with the UI:

deadlock.mp4

As you can see things are working for a while, and then the view model locks up.

This kind of pattern:

var output = inputObservable
            .Select(a =>
                Observable.Start(() => "imagine this string could take a while to calculate")
                    .StartWith("a new value is being calculated")
            )
            .Switch()
            .StartWith("Nothing has been done yet");

Has been my approach to running a function which could take some time asynchronously, with a "loading" value injected into the observable while the program is "thinking". The fact that it is deadlocking seems to indicate that it is not a very good way. I would be grateful to know:

1. Why this is deadlocking
2. How to do what I am trying to achieve in a better way.

[andreas-foreflight]

An update:

I have managed to create a smaller example. The view model now looks like this:

public class DeadlockTestViewModel : ReactiveObject
{
    private readonly ObservableAsPropertyHelper<string> m_observ;
    public string Observ => m_observ.Value;

    private string m_start = "";
    public string Start
    {
        get => m_start;
        set => this.RaiseAndSetIfChanged(ref m_start, value);
    }

    public DeadlockTestViewModel()
    {
        var inputObservable = this.WhenAnyValue(t => t.Start)
            .Throttle(TimeSpan.FromMilliseconds(30));

        var output = inputObservable
            .StartWith("Nothing has been done yet");

        m_observ = output.ToProperty(this, t => t.Observ);
    }
}

This makes the deadlock a bit harder to hit (based on my subjective experience typing random characters into a text field). Changing the throttle timing to 30ms made it a bit easier again, though.

In addition, by just trying a bunch of random stuff, I think I have arrived at a solution which appears to make the issue go away both in the minimal example and in the actual code I am trying to build.

By defining inputObservalbe like this:

var inputObservable = this.WhenAnyValue(t => t.Start)
    .Throttle(TimeSpan.FromMilliseconds(30))
    .ObserveOn(RxApp.TaskpoolScheduler);

I have literally no idea why this works or if it is really a fix, or just makes the timing which causes the deadlock hard enough to hit that I can't trigger it anymore.

I would still really like to know why this happens, and how to write code which does not randomly deadlock with reactive UI. I am pretty nervous about this solution because my understanding is that the schedulers can mean different things on different platforms. Will my code deadlock again if I try to use the view model with Blazor WebAssembly instead of server? Or with MAUI?

Are there a set of practical rules to follow for using these reactive combinators safely? Is causing deadlocks when you don't do things correctly expected?

[JakenVeina]

I think what might be happening is that there isn't a deadlock, but an exception that's killing the stream, because the throttling timer occasionally fires outside of the UI's SynchronizationContext, which results in the possibility that two calls to .StateHasChanged() can be running in parallel, either logically or physically, depending on whether this is Blazor Server or Blazor WASM.

https://github.com/dotnet/AspNetCore.Docs/blob/main/aspnetcore/blazor/components/synchronization-context.md

Blazor doesn't employ a literal main UI thread, in the same sense that WPF or other desktop UI frameworks do, but it does employ a "logical" main UI thread, I.E. UI operations are not built to be thread-safe, and operations affecting UI must be synchronized to run serially, which Blazor does with a SynchronizationContext that apparently queues items on the ThreadPool. Because there is not a literal main thread, Blazor can't do the safety checks that WPF and others do to just throw an exception right away, if you're off the main thread, so the issue becomes more difficult to diagnose.

Regardless of the specifics of this issue, it definitely seems like you should be marshalling that throttled stream back to the "main thread".
.ObserveOn(RxApp.MainThreadScheduler) ought to be the proper way to do this, but RxApp.MainThreadScheduler for Blazor does not actually tie into the SynchronizationContext at all, it just uses CurrentThreadScheduler.Instance. If you make this change and continue to have trouble, I would consider building a scheduler around SynchronizationContext and using that instead.

[andreas-foreflight]

Thank you for taking the time to look into this.

The "Parallel Stacks" view of VIsual Studio shows it as two threads waiting for each others locks:

Thread 20720 (the one with the tall call stack) is waiting in "System.Reactive.Linq.ObservableImpl.Throttle._" on line 59.

Thread 23480 is waiting in "System.Reactive.Linq.ObservableImpl.Buffer.Boundaries._" on line 846.

I am not seeing any exceptions being caught by the Visual Studio debugger.

I am honestly not really sure about what this means, but it looks a bit like two different parts of reactive extensions waiting on each other's locks.

I have done some more experimentation based on the assumption that this issue arises in relation to Throttle. That is, I am using an example that does not try to run any long-running background tasks, which was my original goal. It might be the case that things behave differently when these are introduced back into the mix.

As mentioned in the update above, doing this caused the issue to disappear:

var inputObservable = this.WhenAnyValue(t => t.Start)
    .Throttle(TimeSpan.FromMilliseconds(30))
    .ObserveOn(RxApp.TaskpoolScheduler);

I have experimented a bit further, and this (based on the reply below) also seems to work:

var inputObservable = this.WhenAnyValue(t => t.Start)
     .Throttle(TimeSpan.FromMilliseconds(30), RxApp.MainThreadScheduler);

It seems that, to not "lock up" (whether this is really a deadlock or not), either:

1. Throttle must be passed RxApp.MainThreadScheduler, or
2. Throttle must be "observed on" RxApp.TaskpoolScheduler.

If you do 1 it doesn't matter where you observe. If you do 2, it doesn't matter what you pass to Throttle.

However, if you pass RxApp.TaskpoolScheduler (or nothing, which seems to be equivalent to passing RxApp.TaskpoolScheduler) and "observe on" RxApp.MainThreadScheduler (or not specify where you want to observe, which I suspect might default to RxApp.MainThreadScheduler due to one or both of WhenAnyValue and ToProperty?) then you get this "lock up"

I am not sure that the issue is Blazor being interacted with from the wrong thread/synchronization context. It kind of seems to me like the issue is that Throttle can end up scheduling its timers in a way which causes reactive extensions to break internally depending on where the input and/or output is consumed/comes from.

But at the end of the day, I still don't really understand what is going on here. My main take a way is that Throttle is a scary function.

[anaisbetts]

This snippet of code is effectively recreating ReactiveCommand - you should instead just use ReactiveCommand!

Some Pro-Tips:

// Invoke the command automatically
this.WhenAnyValue(t => t.Start)
  .Throttle(TimeSpan.FromMilliseconds(200), RxApp.MainThreadScheduler)  // XXX: Always always provide a scheduler!
  .InvokeCommand(this, x => x.DoALongThingCommand);

// ...later

// The results of command invocations are themselves Observables, this means you can ToProperty them!
DoALongThingCommand
  .ToProperty(this, x => x.Result, out _Result);

[andreas-foreflight]

This code certainly looks better than by Switch approach, and I have been wondering if there is a better way, because my approach feels slightly convoluted.

But unfortunately, I don't think that it does the same thing?

If a new value arrives while the command is running, it seems (from the documentation and from trying it out) that these values are silently ignored.

My Switch version always switches to the newest input.

I am trying to create a UI which always tries to "keep up with" the user input. So it is okay if it pauses and chills out for a while if too much input is arriving. But it should:

1. somehow reflect that it is currently "loading" when this happens
2. always catch up to the current input when things settle down for a while.
3. preferably, it should not wait too long for an old calculation to finish (or be properly canceled and disposed) if some new input is ready to be calculated on. I am willing to compromise on this and force the user to wait for the consequences of their actions, even if they regret them. (you could also argue that I should just write my code so that it is always easily and quickly cancellable, but this is easier said than done, especially if you are working from existing code).

I am not much of a UI person, but I think that this (at least 1 and 2) is the general expectation for how a "reactive" UI is supposed to work?

My attempt at using a Reactive command looks like this:

public DeadlockTestViewModel()
{
    var command = ReactiveCommand.CreateFromTask<string, string>(Greet);

    this.WhenAnyValue(t => t.Start)
        .Throttle(TimeSpan.FromMilliseconds(30), RxApp.MainThreadScheduler)
        .InvokeCommand(command);

    m_observ = command
        .ToProperty(this, t => t.Observ);
}

public static async Task<string> Greet(string name)
{
    await Task.Delay(100);
    return "Hello, " + name;
}

I don't know if this is what you intended.

---

In regard to the deadlock issue (if it indeed is a deadlock. The UI locks up in any case). I have posted more details in a comment to the answer above.

I find your comment that: .Throttle(TimeSpan.FromMilliseconds(200), RxApp.MainThreadScheduler) // XXX: Always always provide a scheduler! interesting, because this indeed works (in all the examples: The original one with Switch, the simplified one from my update, and this version here with the reactive command).

That is, it works with RxApp.MainThreadScheduler, not just any scheduler.

Is there a good explanation for why this scheduler should be passed to throttle, unless it is observed on RxApp.ThreadpoolScheduler in which case any or no scheduler can be passed. Because I don't really understand the why of it all.