←back to thread

Asynchrony is not concurrency

(kristoff.it)
293 points kristoff_it | 2 comments | 18 Jul 25 19:21 UTC | HN request time: 0.813s | source
Show context
sedatk ◴[18 Jul 25 21:08 UTC] No.44609850[source]▶
Blocking async code is not async. In order for something to execute "out of order", you must have an escape mechanism from that task, and that mechanism essentially dictates a form of concurrency. Async must be concurrent, otherwise it stops being async. It becomes synchronous.
replies(3): >>44610133 #>>44610169 #>>44610264 #
1. nemothekid ◴[18 Jul 25 21:58 UTC] No.44610264[source]▶
Consider:

    readA.await
    readB.await
From the perspective of the application programmer, readA "block" readB. They aren't concurrent.

    join(readA, readB).await
In this example, the two operations are interleaved and the reads happen concurrently. The author makes this distinction and I think it's a useful one, that I imagine most people are familiar with even if there is no name for it.
replies(1): >>44612229 #
2. sedatk ◴[19 Jul 25 03:10 UTC] No.44612229[source]▶
I think that confuses paradigm with configuration. Say, if one thread waits on another to finish, that doesn't mean the code suddenly becomes "single-threaded", it just means your two threads are in a serialized configuration in that instance. Similarly, when async code becomes serialized, it doesn't cease to be async: the scaffolding to make it concurrent is there, it's just unused in that specific configuration.

For example, C# uses this syntax:

   await readA();
   await readB();
when you have these two lines, the first I/O operation still yields control to a main executor during `await`, and other web requests can continue executing in the same thread while "readA()" is running. It's inherently concurrent, not in the scope of your two lines, but in the scope of your program.

Is Zig any different?