Dispatcher.Invoke API Change in v11

[mysteryx93]

This code breaks in v11. Dispatcher.Invoke can no longer have return values?

Why was this change made, and what is a work-around?

protected Task<T> DispatchAsync<T>(Func<T> action) =>
    _dispatcher.CheckAccess() ? Task.FromResult(action()) : _dispatcher.InvokeAsync(action, DispatcherPriority.Render);

My use-case: I want to display a message box on the UI thread even if called from a background thread, and return the selection.

[hez2010]

The Dispatch.InvokeAsync<T> still exists.

Avalonia/src/Avalonia.Base/Threading/Dispatcher.cs

Line 93 in 38fb9f1

public Task<TResult> InvokeAsync<TResult>(Func<TResult> function, DispatcherPriority priority = default)

[mysteryx93]

This alone must be the reason why MvvmDialogs breaks with v11.

AH got it. It's in the Dispatcher, but missing from IDispatcher!

And here's the commit that broke it.

[hez2010]

If you want to workaround InvokeAsync<T> for IDispatcher, you can use TaskCompletionSource<T>:

var tcs = new TaskCompletionSource<T>();
_ = dispatcher.InvokeAsync(() => 
{
    // ...
    tcs.SetResult(...);
}, ...);
var result = await tcs.Task;

[kekekeks]

I think it was removed from IDispatcher during the general removal of generic virtual methods from the codebase. Those are known for bad perf especially in AOT scenarios

[kekekeks]

Note, that there is always only one dispatcher, I think IDispatcher is only used for our internal unit tests. You can safely use Dispatcher.UIThread, we have no plans for multiple UI thread support in the next 1-2 years.

[mysteryx93]

IDispatcher is also useful for my own unit tests.

I think it was removed from IDispatcher during the general removal of generic virtual methods from the codebase. Those are known for bad perf especially in AOT scenarios

Can you explain?

[maxkatz6]

@mysteryx93 it was done in this PR #7980

Generic virtual methods tend to slow down JIT and blob AOT compiled applications. In some cases it's better to replace that with "object" or make it non-virtual so compiled would have an easier job.

[hez2010]

I think it's okay to have some generic virtual methods in interfaces for convenience (especially for IDispatcher.Invoke becuase it's really needed for testing purpose), because we have trimming now, so methods that are not being used can be trimmed away after compilation and performance won't be affected in client applications.

[kekekeks]

We'll need a way to ban the usage of certain methods from our own code then.

[mysteryx93]

It's really needed for testing purpose; but then our code is also based on IDispatcher instead of Dispatcher and calls that generic virtual method which should be avoided...

There's also @hez2010 's work-around.

[timunie]

Converted this into Q&A as this is neither a bug nor a feature request. If you disagree please let us know.

[ArchibaldMacdonald-cyacomb]

We also use IDispatcher for testing purposes, and I agree this makes testing much more difficult.