Hacker News Reader

Comment by mythz | Hacker News Reader

Works for a while, but then trying to do something like processing serial async responses in a loop gets painful without async/await, i.e:

    while (await reader.ReadAsync(cts)) { ... }

View on HN

Why is that easier than using a blocking call directly on the Task object that ReadAsync returns? Like ".Return" or ".Wait"

Because 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-co...

That deals particularly with mixing and matching awaits and Results in complex manner. I wouldn't call "don't do that" "very complicated".

isn'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.

My 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.

yes 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.

Reply on news.ycombinator.com