3 ms·

Threading, probably.

• eddd-ddde 3y ago
  Threading is compatible with async
  • jvanderbot 3y ago
    "threading alone" as in a thread per request.
• littlestymaar 3y ago
  I don't think so, because there isn't a performance drawback compared to threads when using async. In fact there's literally nothing preventing you from using a thread per task as your future runtime and just blocking on `.await` (and implementing something like that is a common introduction to how async executors run under the hood so it's not particularly convoluted). Sure there's no reason to do that, because non-blocking syscalls are just better, but you can…
  • cultureswitch 3y ago
    > I don't think so, because there isn't a performance drawback compared to threads when using async. There is. When you write async functions, they get split into state machines and units of non-blocking work which need to be added and taken from work queues. None of this has to happen if you just spawn an OS thread and tell it "execute this function". No state machine, no work queue. It's literally just another sequential program that can do blocking I/O independently of your main thread. If you insist on implementing a thread-based solution in exactly he same way that an async solution would, then yes they'll both pay the price of the convoluted runtime. The point is, there's no need to do that.
• astrange 3y ago
  Async/await isn't related to threading (although many users and implementations confuse them); it's a way of transforming a function into a suspendable state machine.
  • jvanderbot 3y ago
    I know. But threading, and earlier processes, were less scalable but potentially faster ways of handling concurrent requests.
    • otterley 3y ago
      It's also much easier to reason about, since scheduling is no longer your problem and you can just write sequential code.
      • littlestymaar 3y ago
        That's one way to see it. But the symmetric view is equally valid: async await is easier to reason about because you see were the block points are instead of having to guess which function is blocking or not. In any case you aren't writing sequential code, it's still concurrent code, and there's a trade-off between the writing simplicity of writing it as if it was sequential code, and the reading simplicity of having things written down explicitly. This “write-time vs read-time” trade of is everywhere in programming BTW, that's also the difference between error-as-return-values and exception, or between dynamic typing and static one for instance.
  • orthoxerox 3y ago
    Games need async/await for two main reasons: - coding multi-frame logic in a straightforward way, which is when transforming a function into a suspendable state machine makes sense - using more cores because you're CPU-bound, which is literally multithreading Both cases can be covered by other approaches, though: - submitting multi-frame logic as job parameters to a separate system (e.g., tweening) - using data parallelism for CPU-intensive work