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

Par*_*roX 6 c# asynchronous async-await asp.net-web-api asp.net-web-api2

我有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);
    }
Run Code Online (Sandbox Code Playgroud)

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

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

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

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

Ste*_*ary 15

我绝对不想异步使用该函数.

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

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

我正在寻找解决方法/黑客/建议

我有一篇关于棕色字段异步开发主题的整篇文章,其中我介绍了所有已知的hacks以及它们的缺点.

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

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

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