[Carpetsmoker]

I'm sorry, but this is such a non-answer. What am I supposed to do with this? Clearly things aren't that simple to achieve negligible latency, otherwise we would have it. I bet there are a lot of trade-offs involved here (there usually are), and simply stating "take latency serious" isn't helpful in having any meaningful conversation about this.

[snvzz]

I'd start by doing a PoC of replacing the OS with an RTOS. This would allow for pointing and shaming; Linux/OSX/Windows are to blame.

I would pick seL4 because of their WCET proof.

[Carpetsmoker]

But there are also a lot of drawbacks of RTOS systems, no? Just searching "Real-time operating system downsides" shows a lot of drawbacks that makes it seem like a poor fit for a general-purpose OS: multi-tasking is limited, it's less efficient, and much more complex. There are certain use-cases where this is a good trade-off, but for my desktop OS? Probably not.

[snvzz]

>tradeoffs

It depends on the implementation. Most protected RTOSs are vastly inefficient but it doesn't have to be so.

For an example, many multitasking RTOSs do reserve CPU time for the "important" tasks, whether they use it or not. That's the industry standard for "mixed criticality", where less and more critical tasks share the same CPU.

But there's better ways to do this. Refer to the seL4 whitepaper[0].

>desktop OS

I'd rather not WaitForever™ for the computer to react to my input due to unbounded latency on my Desktop OS. We might be used to trash responsiveness, but interacting with a computer does not have to be this bad. We should stop pretending non-RTOS systems are okay to build a desktop around.

[0]: https://sel4.systems/About/seL4-whitepaper.pdf

[Carpetsmoker]

So what is the latency on seL4 then for a similar program? And how well is the performance under real-world desktop conditions compared to Linux, macOS, Windows, etc? I read through that PDF and it doesn't really contain concrete answers to that.