Hacker News new | ask | show | jobs
by amelius 4100 days ago
Yielding will take CPU time, even when no yielding is necessary. And where to put these yields? In an inner-loop? Should all loops be rewritten to ensure a yield takes place at least every N instructions? Considering all this, I think a better approach would be to optimize the thread scheduler in the kernel, assuming it is as inefficient as you are suggesting.
1 comments

In practice, you indeed yield often enough — there is no perfect formula I believe — so in loops or elsewhere where you are spending too much time doing one thing. You don’t need to do it perfectly, you just need to yield often enough to give other coros a fair chance at completion. Relying on the kernel is a bad idea; that’s where you lose on performance. Also, to do what you are suggestions would mean that you use many, many OS threads and the kernel somewhat manages them all in a pre-emptive fashion, and you don’t need to do it yourself; but that means you need to pay the context switching, memory footprint etc costs. It won’t scale and will be slow.
The memory footprint is there only to provide for stack-space. This makes me wonder, how do coros implement stacks? And don't they suffer effectively from the same problem?

Another point: what if your code calls a library function for which you don't have control over when it yields?