TaskCompletionSource SynchronizationContext

Question

我正在Xamarin iOS应用程序中编写一些基本的Firebase代码，并且在TaskCompletionSource中遇到了典型的死锁情况。

public Task<string> GetUsers()
{
    var tcs = new TaskCompletionSource<string>();
    _instance.GetChild("users").ObserveSingleEvent(DataEventType.Value,
        x => { tcs.SetResult(x); });
    return tcs.Task;
}

当我像这样阻止这个代码时：

var users = GetUsers().Result;

应用程序死锁。

如果我正确理解，回调将试图运行在与.Result等待的上下文相同的环境上。

我不明白的是，如果我修改代码以等待GetUsers()在Task中的调用，如下所示：

var result = Task.Run(
    async () => await AppContext.Database.GetUsers().ConfigureAwait(false)
).Result;

它还是死死的。

第二个案子是怎么回事？由于Task.Run，代码在另一个线程上运行这一事实不应该意味着外部.Result不阻止回调调用吗？

编辑：

在跟进Nkosi的评论之后，我会问这个问题，因为我很好奇为什么代码会阻塞。如果我等电话

var users = await GetUsers().ConfigureAwait(false);

然后僵局就消失了。我只想了解为什么它在包装在Task中时会阻塞，因为根据我对Task.Run (显然不正确)的理解，它不应该阻塞。

Answer 1

ObserveSingleEvent总是将回调分派给UI线程(我认为所有或几乎所有的基本回调都是这样做的)。它不捕获同步上下文或类似的内容--只是总是向UI线程发出回调(记住--它只是本机IOS代码的包装器)。因此，当您通过等待Result来阻塞UI线程时，无论您从哪个线程调用GetUsers，它都会由于明显的原因而陷入死锁。您提到的链接描述了当调用代码捕获当前同步上下文时的另一种情况，因此他们从没有同步上下文的后台线程调用代码，并且回调不会发布到它。这里不是这样的。