Interesting. I don't know much about OSes, but in userspace there's an analog for event loops.<p>Almost all of them have a timer heap or timer wheel or something (that's below the level of abstraction I work at) which can always answer the question, "When do I wake up next?". And then every event is reducible to either a timer timeout or an external event like the file driver giving you data from a file, getting a packet from the network, mouse movement, etc.<p>Games often don't need this because they tick at 60+ Hz to render everything anyway, so it's easier to just hang everything off that and check every timer on every frame, it's going to be a tiny waste of CPU compared to the rest of the game logic.<p>However in one case I was writing an event-based program for work, using C++, with limitations on what dependencies I could pull in, so I set a fixed tick (something like every 1 second) and when I got external events, I just ran the whole tick function instantly. This introduced some latency but it was in places that didn't matter, and it made the code really easy to follow.
It's easy to assume OS schedulers have a lot of intellect behind them, but in reality, like most software, they're often shipped in a half-baked state. Even mature schedulers like the Linux kernel are far from perfect.<p>It surprised me that yield wasn't a concept from the beginning for this RTOS (reading it, when they started describing the problem, I was already asking "why aren't they yielding instead of sleeping?"), but glad to see the improvement in the next paragraph.<p>There are always things to improve, which I find refreshing - I hope AI doesn't take that away. Or if it does, it had better also eliminate poverty, war, etc. Let people spend their days playing.
> almost all of the calls to thread_sleep wanted to yield to allow another thread to make progress, rather than to guarantee some time had elapsed.<p>That's .. deeply alarming and likely indicates the bad code. I've seen many beginner programmers use sleep/yield to busy-wait on something, and it's almost always a bad design decision: using proper synchronization primitive would be safer and more performant too.<p>Just to make sure that my guess was correct, I've searched CHERIoT codebase for some thread_sleep calls. There were only 15 hits, and most of them were related to implementation; only two examples were actual use in the code: busy-wait in TLS stack and polling for response in SNTP driver. Both of those are bad design - they should be using proper synchronization mechanisms.