Thanks. > polling is only explained as a logical thing But there is the poll() function that returns either the result of the operation, or "pending". So it's

Thanks. > polling is only explained as a logical thing But there is the poll() function that returns either the result of the operation, or "pending". So it's more than logical. Correct? I mean, if I (or the executor) don't call poll() nothing happens... > OS thread now switching to execute whatever it is that it is waking up. This is what confuses me. As I see it (and I what I understand from reading), async/await splits a routine into a (very smart) state machine. I assume that there is no magic underneath. I mean, I can do the same state machine by hand if I want to, under the constraints of what the OS makes available for me in what context switching regards (APIs for waiting and synchronizing). For a (OS/native) thread that has to wait for data on a socket, you have (basically) two options: wait on recv() or poll recv() without timeout. Waiting on recv() would block (so no other code of my thread can be executed while waiting), so I guess the state machine needs to poll on recv() (I believe this is what this[1] example does). In order to no block my thread, the executor either spins its own thread, or has to wait for my thread to poll() it. [1] https://rust-lang.github.io/async-book/02_execution/02_future.html https://rust-lang.github.io/async-book/02_execution/02_futur...