c# – 即使使用ConfigureAwait,也会在WebAPI死锁中同步调用异步方法(false)

我有nuget包 Esri.ArcGISRuntime,我需要在我的一个Web API 2控制器中调用方法 QueryTask.ExecuteAsync.没有同步计数器部分所以在我的库c#代码中我使用的是包装器

private QueryResult ExecuteSync()
    {
        var queryResults = ExecuteAsync();
        queryResults.Wait();
        return queryResults.Result;
    }

    private async Task<QueryResult> ExecuteQueryTaskAsync()
    {
        var queryTask = new QueryTask(_uri);
        return await queryTask.ExecuteAsync(_query).ConfigureAwait(false);
    }

这在我的程序/服务中完美运行.但是在Web API 2控制器中以这种方式使用ExecuteSync会导致它完全冻结并且永远不会返回响应.

我做了一些研究,并相信罪魁祸首在这里提到：
http://blog.stephencleary.com/2012/07/dont-block-on-async-code.html

我绝对不想异步使用该函数.上面的函数是如此核心并且隐藏在4个包装器的深处,这将是我的库类的一个重大改进,冒泡异步方法只是为了支持这个web api调用.

我正在寻找围绕这个奇怪的Web API行为的解决方案/黑客/建议,以允许我同步运行这个异步方法,而不是让它死锁

解决方法

I absolutely do not want to use the function asynchronously.

不过我不得不说.异步代码是最好的解决方案.您正在执行的操作是异步的,并且为其公开同步API最多也是有问题的.

需要时间吗？当然.但是你的代码会更好.

I am looking for work-arounds/hacks/suggestions

我有 an entire article on the subject of brownfield async development,在那里我涵盖了所有已知的黑客以及它们的缺点.

在您的特定情况下(从非核心ASP.NET上的WebApi调用,并考虑它可以从Console / Win32Service样式的应用程序工作),我会说Thread Pool Hack应该适合您.它看起来像这样：

private QueryResult ExecuteSync()
{
  return Task.Run(() => ExecuteAsync()).GetAwaiter().GetResult();
}

想法是ExecuteAsync在请求上下文之外的线程池线程上运行.然后阻止请求线程,直到异步工作完成.

c# – 即使使用ConfigureAwait,也会在WebAPI死锁中同步调用异步方法(false)

解决方法

相关文章