4 ms·

polling is only explained as a logical thing. In reality the given task is only marked to be woken up later. The later being some other point, while the same OS

by harikb 6y ago

polling is only explained as a logical thing. In reality the given task is only marked to be woken up later. The later being some other point, while the same OS thread executing something else, when the executor determines that the idling task can be woken up. "Waking" is nothing but the same OS thread now switching to execute whatever it is that it is waking up. Main idea is that a 'scheduler/executor' at the runtime/language level that knows about the state of the program can (a) 'save' and 'restore' fewer things compared to an OS context switch. (b) co-operative stuff does not need to pay the cost of too many unnecessary pre-emptions

scoutt 6y ago
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...

by harikb 6y ago

scoutt 6y ago

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...