我有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调用.
解决方法
@H_404_16@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在请求上下文之外的线程池线程上运行.然后阻止请求线程,直到异步工作完成.
