-2

I have just started working on Asp.Net Core. While using SignInManager class, I noticed that many methods of SignInManager class are async inluding

PasswordSignInAsync() and SignOutAsync()

According to answers of Why shouldn't all functions be async by default? ; "the purpose of async/await is to make it easier to write code in a world with many high latency operations".

I don't think that login related operations should have been considered as "high latency operations" so what is the idea behind of having async/await in SignInManager class?

doganak
  • 798
  • 14
  • 31
  • 3
    Hitting an external database isn't a "high latency operation"? Given that synchronous IO is all but prohibited under dotnet core, I don't see many options here. – spender Mar 25 '18 at 23:06
  • And how about external login/authentication providers that require network communications...and "handshakes"? – EdSF Mar 25 '18 at 23:06
  • 1
    There is a strong desire in dotnet core to eliminate synchronous IO altogether. The clear message from dotnet core (and many recent .net libraries) is "sync IO ain't cool". For instance, `HttpClient` doesn't do sync. Login related functions are very likely to leverage some sort of IO. Put these nuggets together, and there's your answer. – spender Mar 25 '18 at 23:17

2 Answers2

1

Typically, UserManager calls indirectly will rely on databases and external services, so it kind of makes sense to have async methods at all, perhaps even as the default option.

The reason why there are no sync versions of those methods isn't immediately clear. Perhaps if you dig deep enough in the commit logs or issues on GitHub you might find the reasoning. Barring those options, you can only either speculate, or ask the original authors. (On a related note, someone already asked for sync versions of methods).

Jeroen
  • 60,696
  • 40
  • 206
  • 339
0

Timescales in computing are important to consider for this. In human terms, all the operations I'll describe below are faster than the blink of an eye.

If you scaled up one CPU cycle to 1 second, accessing RAM would take a few minutes, and accessing SSD storage would take a few days. I believe that from an API designer's perspective, it's reasonable to assume that accessing the backing store of a user database would take at least as long as accessing SSD storage.

That certainly true once you start considering external authentication providers, which will be calls over the internet.

jdphenix
  • 15,022
  • 3
  • 41
  • 74