在同步异步避免死锁，并防止敏感的UI [英] Sync over Async avoiding deadlock and prevent UI from being responsive

问题描述

我们有一个正在使用WPF和/或的Winforms客户库

我们已经提供了类似的异步方法：

 任务< INT> GetIntAsync（）
  

我们也已经（不幸）提供的同步封装方式：

  INT调用getInt（）; 
  

基本上只是调用的异步方法和调用。结果上的任务。

我们最近在某些情况下实现了一些代码的 GetIntAsync 需要在主UI线程上运行（需要使用标记为单次线程模型的传统COM组件（即组件必须在主STA线程不是任何STA线程中运行）

所以问题就是当调用getInt（）被称为主线程，它将僵局，因为

• 的。结果块为主线，


• 中的代码 GetIntAsync（）使用 Dispatcher.Invoke 来尝试在主线程上运行。

同步方法已经被消耗，因此将是一个重大更改删除它因此，不是，我们已经选择了使用的在我们的同步调用getInt（）方法WaitWithPumping 允许调用到主线程工作。

这工作得很好，除了使用调用getInt（）从UI代码的客​​户。此前，他们预计使用调用getInt（）将离开自己的用户界面反应迟钝 - 也就是说，如果他们叫​​调用getInt（）从按钮的单击事件处理程序中，他们会认为没有窗户的消息被处理，直到处理程序返回。现在，消息被抽到，其UI的是响应和相同的按钮可以再次被点击（他们可能没编写自己的处理程序是重入）。

如果有一个合理的解决方案，我们希望不会有我们的客户需要编写针对用户界面调用getInt <在通话过程中是响应/ p>

问：

• 有没有办法来做一个 WaitWithPumping ，将泵援引主的消息，但不抽其他UI相关的消息？


• 这将足以满足我们的目的如果当前被证明的表现好像一个模态对话框客户端UI，尽管隐藏（也就是用户无法访问其他窗口）。但是，从我读，你不能隐藏一个模式对话框。


• 您能想到的，将不胜感激。

$ B $其他解决方法b

解决方案

而不是利用你可以调用getInt 的范围内创建自己的消息泵现有的消息泵。 这里是博客条目讨论如何写一个。 这是。完整的解决方案的博客创建

使用，你可以写为：

 公众诠释调用getInt（）
 {
返回AsyncPump.Run（（）=> GetIntAsync（））; 
} 
  

这将导致完全阻塞UI线程不如预期，同时仍然保证所有从 GetIntAsync 叫做延续不死锁，因为他们将被编排到一个不同的的SynchronizationContext 。另外请注意，此消息泵仍然是主要的STA / UI线程上运行。

We have a library that is being used by WPF and/or Winforms clients.

We've provided an asynchronous method similar to:

Task<int> GetIntAsync()

We've also (unfortunately) provided a synchronous wrapper method:

int GetInt();

which essentially just calls the asynchronous method and calls .Result on its task.

We recently realized under certain circumstances some code in the GetIntAsync needs to run on the main UI thread (it needs to use a legacy COM component that is marked as "Single" Threading model (i.e. the component must run in the main STA thread not just any STA thread)

So the problem is that when GetInt() is called on the main thread, it will deadlock since

• the .Result blocks the main thread,
• the code within GetIntAsync() uses Dispatcher.Invoke to attempt to run on the main thread.

The synchronous method is already being consumed so it would be a breaking change to remove it. So instead, we've opted for using the WaitWithPumping in our synchronous GetInt() method to allow the invoking to the main thread to work.

This works fine except for clients that use GetInt() from their UI code. Previously, they expected that using GetInt() would leave their UI unresponsive--that is, if they called GetInt() from within a button's click event handler, they would expect that no windows messages were processed until the handler returned. Now that messages are pumped, their UI is responsive and that same button can be clicked again (and they probably didn't code their handler to be re-entrant).

If there is a reasonable solution, we'd like to not have our clients need to code against the UI being responsive during a call to GetInt

Question:

• Is there a way to do a WaitWithPumping that will pump "Invoke to main" messages, but not pump other UI related messages?
• It would suffice for our purposes if the client UI behaved as if a modal dialog were currently shown, albeit hidden (i.e. user couldn't access the other windows). But, from what I read, you cannot hide a modal dialog.
• Other workarounds you can think of would be appreciated.

解决方案

Rather than utilizing the existing message pump you can create your own message pump within the context of GetInt. Here is a blog entry discussing how to write one. This is the full solution the blog creates.

Using that you can write it as:

public int GetInt()
{
    return AsyncPump.Run(() => GetIntAsync());
}

That will result in completely blocking the UI thread as expected, while still ensuring that all continuations called from GetIntAsync don't deadlock as they'll be marshaled to a different SynchronizationContext. Also note that this message pump is still running on the main STA/UI thread.

这篇关于在同步异步避免死锁，并防止敏感的UI的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！