3 ms·

I continue to find using explicit "Task<T>" types directly more intuitive. I've wedged in ASync/Await here and there to see if I felt good about it, but I neve

I continue to find using explicit "Task<T>" types directly more intuitive. I've wedged in ASync/Await here and there to see if I felt good about it, but I never did. I would always find declaring a Task and attaching to it's ContinueWith (or whatever I needed ) to be more to my liking.

deleted 12y ago
[deleted]
mythz 12y ago
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)) { ... }
- 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 ago
    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-code.html http://blog.stephencleary.com/2012/07/dont-block-on-async-co...
    - jasallen 12y ago
      That deals particularly with mixing and matching awaits and Results in complex manner. I wouldn't call "don't do that" "very complicated".
  - contextfree 12y ago
    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.
  - jasallen 12y ago
    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.
    - mythz 12y ago
      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.
reubenbond 12y ago
ContinueWith is fine for simple flows, but things fall apart when you need to perform multiple async operations with the same error handling. You either repeat yourself or you put the error handling code into a lambda and make sure you always pass it along. Assuming you just want to propagate exceptions, you have to mess with TaskContinuationSource (I.e, promises) and be damn certain you have wired it into all the right places. Async/await makes error handling much more uniform and "obviously correct" than stringing callbacks together.
- jasallen 12y ago
  Exception propagation is one area I have to agree. Still, there was no reason to invent whole new language semantics for that. As far as simple flows, I'll disagree. The Task Library allows for normal workflow operations and your decisions are much more (to me) explicit when you see "WaitAll", "WaitAny" chaining things together.
  - contextfree 12y ago
    await isn't an alternative to TPL/Tasks, it's a feature that improves a certain common use case of TPL/Tasks. "await foo" means (roughly[1]) "yield and schedule the current continuation to be run on completion of foo". What really requires language support is the "current continuation" bit, which starts to become tricky/convoluted to express directly once control flow comes in. For any use case other than this there are other tools, such as WaitAll/WaitAny as you say. [1] http://stackoverflow.com/questions/4070237/how-could-the-new-async-feature-in-c-sharp-5-0-be-implemented-with-call-cc/4071015#4071015 http://stackoverflow.com/questions/4070237/how-could-the-new...
    - jasallen 12y ago
      Noone suggested it was not built on top of Tasks. I make it a rule never to question Eric Lippert, and I won't do so here. That said, right, the current continuation bit requires IL foo, but as the ones writing the code, there is always a way besides needing the current continuation bit. And if you're going between languages much at all, Tasks are a lot more like promises and other paradigms in other languages. Whereas the whole await business is just... weird.

deleted 12y ago

[deleted]

mythz 12y ago

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)) { ... }

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 ago
  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-code.html http://blog.stephencleary.com/2012/07/dont-block-on-async-co...
  - jasallen 12y ago
    That deals particularly with mixing and matching awaits and Results in complex manner. I wouldn't call "don't do that" "very complicated".
- contextfree 12y ago
  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.
- jasallen 12y ago
  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.
  - mythz 12y ago
    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.

reubenbond 12y ago

ContinueWith is fine for simple flows, but things fall apart when you need to perform multiple async operations with the same error handling. You either repeat yourself or you put the error handling code into a lambda and make sure you always pass it along. Assuming you just want to propagate exceptions, you have to mess with TaskContinuationSource (I.e, promises) and be damn certain you have wired it into all the right places. Async/await makes error handling much more uniform and "obviously correct" than stringing callbacks together.

jasallen 12y ago
Exception propagation is one area I have to agree. Still, there was no reason to invent whole new language semantics for that. As far as simple flows, I'll disagree. The Task Library allows for normal workflow operations and your decisions are much more (to me) explicit when you see "WaitAll", "WaitAny" chaining things together.
- contextfree 12y ago
  await isn't an alternative to TPL/Tasks, it's a feature that improves a certain common use case of TPL/Tasks. "await foo" means (roughly[1]) "yield and schedule the current continuation to be run on completion of foo". What really requires language support is the "current continuation" bit, which starts to become tricky/convoluted to express directly once control flow comes in. For any use case other than this there are other tools, such as WaitAll/WaitAny as you say. [1] http://stackoverflow.com/questions/4070237/how-could-the-new-async-feature-in-c-sharp-5-0-be-implemented-with-call-cc/4071015#4071015 http://stackoverflow.com/questions/4070237/how-could-the-new...
  - jasallen 12y ago
    Noone suggested it was not built on top of Tasks. I make it a rule never to question Eric Lippert, and I won't do so here. That said, right, the current continuation bit requires IL foo, but as the ones writing the code, there is always a way besides needing the current continuation bit. And if you're going between languages much at all, Tasks are a lot more like promises and other paradigms in other languages. Whereas the whole await business is just... weird.