c# - ReplaySubject.First() 意外阻塞

Question

我在我正在处理的 Silverlight 应用程序中遇到了一个绝对奇怪的行为。请看下面的代码:

var replaySubject = new ReplaySubject<string>(1);
    replaySubject.OnNext("This can never block... surely?");

var s = replaySubject.First();
Debug.WriteLine(s);

基本上，我的应用程序通过重复这段代码来完成，它总是打印出消息...除了在一个特定的场景中，线程阻塞在 First() 行。

它总是在 UI 线程上。如果我在 First() 行上设置一个断点，并使用调试器深入到 replaySubject，我可以在其队列中看到该字符串。

谁能想到会导致 First() 调用在此处阻塞的任何情况？

顺便说一句:它是 RX 版本 1.1.11111

Answer 1

好的，事实证明，默认情况下，ReplaySubject 使用 Scheduler.CurrentThread。

如果我明确地将 ReplaySubject 设置为使用 Scheduler.Immediate 或 Scheduler.ThreadPool，那么它会按预期工作。

var replaySubject = new ReplaySubject<string>(1, Scheduler.Immediate);
    replaySubject.OnNext("This can never block... surely?");

var s = replaySubject.First();
Debug.WriteLine(s);

我仍然需要调查 UI 线程是如何在我的特定场景中陷入困惑的，但现在，这解决了问题。

--- 已编辑 ---

OK，进一步调查发现，上面这段代码大部分时间都是在ThreadPool线程上发起的。尽管当它到达代码时，它在 Dispatcher 线程上，Scheduler.CurrentThread 将 ReplaySubject 放回原始 ThreadPool 线程。

然而，在它崩溃的场景中，一切都从用户点击一个按钮开始。这显然是在 UI 线程上，当它到达这段代码时，Scheduler.CurrentThread 现在是 UI 线程，并且由于我们已经在 UI 线程上，所以出现了死锁。首先是等待 ReplaySubject 抽水——但是抽水排在当前操作的后面。微妙且需要注意的事项。