Is it possible to force the Task returned back from Observable.ToTask() to run continuations asynchronously?

[fedeAlterio]

Consider this snippet:

var sample = new Sample();
_ = Task.Run(async () =>
{
    await Task.Delay(1000);
    Console.WriteLine("Notifying 3");
    sample.NotifyNumber(3); // Hanging on Console.ReadKey();
    Console.WriteLine("We never reach that line");
    sample.NotifyNumber(4); 
});

await sample.WaitForNumberAsync(3);
Console.ReadKey();

class Sample
{
    readonly ISubject<int> _numbersSubject = Subject.Synchronize(new Subject<int>());
    public Task WaitForNumberAsync(int number) => _numbersSubject.Where(x => x == number).Take(1).ToTask();
    public void NotifyNumber(int number) => _numbersSubject.OnNext(number);
}

Since .ToTask() uses internally a TaskCompletionSource, and the parameter TaskCreationOptions.RunContinuationsAsynchronously is not specified, the task continuations are executed synchronously (at least in 99% of the cases) on the thread that calls OnNext(). To fix this issue we can just add a Task.Yield() after the .ToTask(), in that way:

class Sample
{
    readonly ISubject<int> _numbersSubject = Subject.Synchronize(new Subject<int>());
    public async Task WaitForNumberAsync(int number)
    {
        var result = await _numbersSubject.Where(x => x == number).Take(1).ToTask();
        await Task.Yield();       
    }
    public void NotifyNumber(int number) => _numbersSubject.OnNext(number);
}

What do you suggest in this scenario? Why not to expose the TaskCreationOptions with another overload of the .ToTask() extension method?
Thank you!

[quinmars]

There is a ToTask overload that takes a scheduler as argument, so in principle .ToTask(TaskPoolScheduler.Instance) should do the trick.

[fedeAlterio]

Thanks for the answer.
I was looking at the source and .ToTask(TaskPoolScheduler.Instance) should be close to .ToTask().ContinueWith(static () => Task.Run(static () => {})) but with an extra overhead due to the fact that the reactive scheduler does not work with Tasks (there is a further TaskCompletionSource allocated to perform the "conversion"). Also sometimes there is a double scheduling that could be avoided:

Imagine for example we are awaiting the ToTask() from a UI Thread, but the OnNext() is called on the ThreadPool. In that case the continuation is forced to run asynchronously by the fact we are awaiting a Task and continuations must run on the caller context by default. So in that case there is no need to pass through TaskPoolScheduler.Default because basically "we are scheduling to the thread pool, just to schedule on the UI immediately", we could just schedule on the UI. These problems are already solved in an efficent way with the parameter TaskCreationOptions.RunContinuationsAsynchronously