回答編集履歴
1
内容の補足
test
CHANGED
@@ -254,6 +254,30 @@
|
|
254
254
|
|
255
255
|
}
|
256
256
|
|
257
|
-
|
258
|
-
|
259
257
|
```
|
258
|
+
|
259
|
+
追記)
|
260
|
+
|
261
|
+
SynchronizationContextによっては、実行スレッドによりawait後のスレッドに制約がかかるため、Task.Waitと競合してデッドロックすることがあります。
|
262
|
+
|
263
|
+
コンソールアプリ以外で使用するケースでは、そのようなケースが起こりうるので、ご注意ください。
|
264
|
+
|
265
|
+
例えば、これ100msくらいで終わるからUIスレッドで実行しよう、とかすると、100ms経過しても返ってこず、固まるということです。確実にUIスレッド以外から実施してください。ASP.NETでの回避方法は未確認です。
|
266
|
+
|
267
|
+
ConfigureAwaitによる回避は↓の記事にもある通りやめるべきだと思います。
|
268
|
+
|
269
|
+
|
270
|
+
|
271
|
+
デッドロックについては、↓が詳しいです。
|
272
|
+
|
273
|
+
http://blog.stephencleary.com/2012/07/dont-block-on-async-code.html
|
274
|
+
|
275
|
+
|
276
|
+
|
277
|
+
SynchronizationContextについては、↓参照です。
|
278
|
+
|
279
|
+
https://msdn.microsoft.com/magazine/gg598924.aspx
|
280
|
+
|
281
|
+
|
282
|
+
|
283
|
+
最後に、納得の行かない人もいるかもしれないので、書いておきますが、待ち合わせという性格上、このI/Fをawaitで実装する限り、Task.Waitは仕方のない選択です。有効なケースであれば問題はないので、個人的に分かって使う分には益がある、と考えています。
|