5 ms·

Since you mentioned C# and most replies so far are about Javascript - In C#, you can't use the "await" keyword, but you can use the result of a Task<T> in a no

by Bieberfan2003 5y ago

Since you mentioned C# and most replies so far are about Javascript - In C#, you can't use the "await" keyword, but you can use the result of a Task<T> in a non-async function with ".Result" or ".GetAwaiter().GetResult()". https://stackoverflow.com/a/47648318/5107208 https://stackoverflow.com/a/47648318/5107208

darklion 5y ago
Unfortunately, there are problems with both of those approaches: https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/blob/master/AsyncGuidance.md#avoid-using-taskresult-and-taskwait https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/b... I don't know if it extends to other language implementations, but C# does not seem to have a reliable sync-over-async story.
- tragictrash 5y ago
  Seems pretty standard to me. Every platform has problems just like this, nothing new there afaik.
Merad 5y ago
Note that it's recommend that you avoid using these because they carry a risk of deadlock. Unless something has changed recently .Net doesn't have a 100% safe way to synchronously call an async method from a non-async method.
- klodolph 5y ago
  I mean, depends on what you mean by "100% safe". You can synchronously wait from a thread that's not in the thread pool executing the tasks. Obviously that's not sufficient for safety, but it should be illustrative that safety is possible. There are also some issues with using .Wait or .Result but those can be solved.
- endorphine 5y ago
  Can you elaborate on why there's a risk of a deadlock?
  - Merad 5y ago
    The very short version is that by synchronously blocking on the async method your thread may end up holding a resource (thread context info or the calling thread itself) that the async method needs in order to run its continuations. Here are a couple of more detailed explanations: https://blog.stephencleary.com/2012/07/dont-block-on-async-code.html https://blog.stephencleary.com/2012/07/dont-block-on-async-c... https://devblogs.microsoft.com/pfxteam/await-and-ui-and-deadlocks-oh-my/ https://devblogs.microsoft.com/pfxteam/await-and-ui-and-dead...
    - endorphine 5y ago
      Now that's pretty much the answer I was looking for, I believe. This makes things much clearer!

darklion 5y ago

Unfortunately, there are problems with both of those approaches: https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/blob/master/AsyncGuidance.md#avoid-using-taskresult-and-taskwait https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/b... I don't know if it extends to other language implementations, but C# does not seem to have a reliable sync-over-async story.

tragictrash 5y ago
Seems pretty standard to me. Every platform has problems just like this, nothing new there afaik.

Merad 5y ago

Note that it's recommend that you avoid using these because they carry a risk of deadlock. Unless something has changed recently .Net doesn't have a 100% safe way to synchronously call an async method from a non-async method.

klodolph 5y ago
I mean, depends on what you mean by "100% safe". You can synchronously wait from a thread that's not in the thread pool executing the tasks. Obviously that's not sufficient for safety, but it should be illustrative that safety is possible. There are also some issues with using .Wait or .Result but those can be solved.
endorphine 5y ago
Can you elaborate on why there's a risk of a deadlock?
- Merad 5y ago
  The very short version is that by synchronously blocking on the async method your thread may end up holding a resource (thread context info or the calling thread itself) that the async method needs in order to run its continuations. Here are a couple of more detailed explanations: https://blog.stephencleary.com/2012/07/dont-block-on-async-code.html https://blog.stephencleary.com/2012/07/dont-block-on-async-c... https://devblogs.microsoft.com/pfxteam/await-and-ui-and-deadlocks-oh-my/ https://devblogs.microsoft.com/pfxteam/await-and-ui-and-dead...
  - endorphine 5y ago
    Now that's pretty much the answer I was looking for, I believe. This makes things much clearer!