3 ms·

Important: following #prefer-asyncawait-over-directly-returning-task from https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/blob/master/AsyncGuidance.m

Important: following #prefer-asyncawait-over-directly-returning-task from https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/blob/master/AsyncGuidance.md#prefer-asyncawait-over-directly-returning-task https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/b... is not correct. The concerns raised are niche and edge case and task must always be forwarded as is provided there is no post-processing or resource cleanup with idisposable. I wish Mr. Fowl had more time to modernize the guide and remove other snippets that are no longer recommended like creating long-running tasks. (it is more efficient, and threadpool can perfectly cope with it, to just moderately block the worker threads when no other option is available, and nowadays there are better tools like Channel<T> over BlockingCollection<T>)

jddj 3y ago
There are a lot of points in that readme and not so many in this comment. Can you justify further?
- neonsunset 3y ago
  Yes. The correct approach to this is await return has to be justified. Doing more work has to justify why this work is being done - because return await produces a whole another state machine box and async call overhead. Something that future async2 project will solve without any code changes, but hasn't become the reality just yet. The exact example in the advice is an anti-pattern (single-statement method call) that some analyzers will luckily complain about. In order for the advice to be correct the method body should actually have either AsyncLocal declaration (exceedingly rare), or care about exact stack trace (also rare, do not rely on this as it's not guaranteed either way). If the code has a disposable, there will be a warning that returning a task of out using may be undesirable (it is common knowledge at this point). Hence the example is as much of a mistake as doing `return await Task.FromResult(value)` over just `return value`.
  - jddj 3y ago
    > Hence the example is as much of a mistake as doing `return await Task.FromResult(value)` over just `return value`. We have some of these as well. Thanks, seems like it's time for some introspection.

jddj 3y ago

There are a lot of points in that readme and not so many in this comment. Can you justify further?

neonsunset 3y ago
Yes. The correct approach to this is await return has to be justified. Doing more work has to justify why this work is being done - because return await produces a whole another state machine box and async call overhead. Something that future async2 project will solve without any code changes, but hasn't become the reality just yet. The exact example in the advice is an anti-pattern (single-statement method call) that some analyzers will luckily complain about. In order for the advice to be correct the method body should actually have either AsyncLocal declaration (exceedingly rare), or care about exact stack trace (also rare, do not rely on this as it's not guaranteed either way). If the code has a disposable, there will be a warning that returning a task of out using may be undesirable (it is common knowledge at this point). Hence the example is as much of a mistake as doing `return await Task.FromResult(value)` over just `return value`.
- jddj 3y ago
  > Hence the example is as much of a mistake as doing `return await Task.FromResult(value)` over just `return value`. We have some of these as well. Thanks, seems like it's time for some introspection.