3 ms·
That’s what I was thinking. I mean, sure, I’d wish all our code was modern and new, but it’s not. And I can’t just magically make everything async, yet many dev
by Semaphor 2y ago
That’s what I was thinking. I mean, sure, I’d wish all our code was modern and new, but it’s not. And I can’t just magically make everything async, yet many devs *including MS* think modern code should not offer synchronous APIs. And so I need to call async APIs from synchronous code.
- Hawxy 2y agoThe article continues with all of the different ways you could do sync-over-async and all of them have downsides. There's no "good" solution that could be recommended. The community consensus is to do `GetAwaiter().GetResult()` and simply accept it's not an ideal usage.
- Kuinox 2y agoGetAwaiter().GetResult() can result in deadlocks. The ideal solution is to split the code and continue the execution through an event/continuation/queue, etc...
- pif 2y ago> The ideal solution is to split the code I'm sorry, it looks like you did not get the problem: you receive a Task, and you are in a sync environment, and you don't have control over these two constraints. How do you safely wait for the Task to complete?
- Semaphor 2y agoIt was more targeted at libraries not including sync methods anymore :(
- pif 2y agoIt's not a point of honour for MS developers that such a known problem has no good (TM) solution!