dysfun@treehouse.systems ("gaytabase") wrote:
it is of course a single threaded green thread scheduler. it's atomic free for local green threads to wake each other, it's wait free for remote threads to wake local threads and it tries to mitigate the kernel picking the worst possible time to swap the remote threads wanting to wake out by finding something else to do. oh yeah and the local queue can be pushed at both ends giving you effectively two service classes.
why? because if a green thread would otherwise get stuck in a spin loop, it can just request a little break cheaply instead of spinning and we can process something else.
reasoning here is that spin loops often happen because something got swapped out by the kernel at an inappropriate time. you see this in rust futures a lot. this way green threads (our analogue of futures tasks) can just request some time out to process something else if it passes a threshold.