3 ms·
You can actually just use `.Wait` or `.Result()` most of the time if you just want to make it synchronous if it's just scrappy code. Though you'll probably hit
by mattmanser 6y ago
You can actually just use `.Wait` or `.Result()` most of the time if you just want to make it synchronous if it's just scrappy code.
Though you'll probably hit the `async void return` runtime bug at some point where you accidentally return void from a method you tried to make async but then got bored of rewriting everything, so just whack in a .Wait or .Result() but haven't returned Task and the damn thing fails at runtime with a mysterious error making you curse async even more.
- nullsense 6y ago>You can actually just use `.Wait` or `.Result()` most of the time if you just want to make it synchronous if it's just scrappy code. You call .GetAwaiter().GetResult(); and avoid mixing sync and async where at all possible.
- ddek 6y agoNever, ever, ever do this in production. This will block at least two threads, which will cause premature thread pool starvation at spike loads. This pattern, 'sync-over-async', is to be avoided at all costs, at all times. You're not going to like it, but the MS recommended way of dealing with this is to make your callstack async. In all honest - if you're making an ASP net core web app, go all in on async from the start. If you have to mix and match, never go sync-over-async inside an action.