4 ms·
Why is that easier than using a blocking call directly on the Task object that ReadAsync returns? Like ".Return" or ".Wait"
by jasallen 12y ago
Why is that easier than using a blocking call directly on the Task object that ReadAsync returns? Like ".Return" or ".Wait"
- Strilanc 12y agoBecause blocking on tasks is a deadlock waiting to happen [0], and creates UI hiccups when the task takes longer than 16ms to complete. In other words, the conditions you must satisfy for using Task.Wait or Task.Result are very complicated. They depend on and create global constraints of the entire program, and so you should avoid using them whenever possible. 0: http://blog.stephencleary.com/2012/07/dont-block-on-async-code.html http://blog.stephencleary.com/2012/07/dont-block-on-async-co...
- jasallen 12y agoThat deals particularly with mixing and matching awaits and Results in complex manner. I wouldn't call "don't do that" "very complicated".
- contextfree 12y agoisn't this whole discussion predicated on not wanting to block? if you don't care about that there's no need to call a Task-returning method in the first place.
- jasallen 12y agoMy mistake and too late to edit. I don't use "await" and I misread this at first. Actually the classic tasks way would be to add these to an array of tasks, and then "WhenAll" for the continuation.
- mythz 12y agoyes it's easier to fire and wait for async tasks in parallel - but I specifically mentioned processing serial async responses, i.e. sequentially like a normal for loop.