But it doesn't have to work that way. The scheduler could scan the whole (unsorted) list at each tick to see if anything is due. No scheduler worth a jot in production is going to do that, but it could.
Saying that sleep sort is really some better form of insertion sort for this reason seems wrong. You might as well say it is bogosort because the scheduler could be using that (and with 1s sleeps it would be faster than sleepsort most of the time despite being generally worse by normal analysis methods).
If a compiler unrolls a short loop to get an extra lick of speed from the tight outer loop, I don't claim I've been clever¹ and spotted the potential optimisation, I probably don't even know it had happened.
--
[1] At a stretch I could claim the opposite: to be clever because I've resisted the urge to over-optimise manually, potentially producing something less performant than a good compiler would on some/all architecture targets while making the code less maintainable too.
Well, this would depend totally on how the scheduler has been implemented. I will give you an analogy for a simple implementation:
Suppose we receive 10 numbers as inputs. We set up 10 cars around a race track with the numbers as their race numbers and set their speeds to the numbers we received as inputs respectively. Now the judge(scheduler) checks at a fixed small interval which car crossed the line and notes down the order. This list gives us the numbers in a sorted order.
This implementation would be very naive but as I said it totally depends on scheduler internals. Modern deadline schedulers would sort the tasks by their deadline times and that's totally correct. Just pointing this out.
Bingo. Whenever new coroutines are scheduled to be executed sometime in the future, something somewhere needs to keep them sorted so that the event loop knows how to dequeue them.
It's funny to show this to someone new to CS, but I wouldn't be surprised if you could look at the source for the asyncio implementation and figure out exactly what sorting algorithm you are "actually" using.
Saying that sleep sort is really some better form of insertion sort for this reason seems wrong. You might as well say it is bogosort because the scheduler could be using that (and with 1s sleeps it would be faster than sleepsort most of the time despite being generally worse by normal analysis methods).
If a compiler unrolls a short loop to get an extra lick of speed from the tight outer loop, I don't claim I've been clever¹ and spotted the potential optimisation, I probably don't even know it had happened.
--
[1] At a stretch I could claim the opposite: to be clever because I've resisted the urge to over-optimise manually, potentially producing something less performant than a good compiler would on some/all architecture targets while making the code less maintainable too.