That's just another user process. So everything else will continue. You have to let go of your macro kernel mindset if you want to make sense of the timing in a micro kernel environment. Blocking threads is fine. Just make sure that you don't do that sort of stuff in your UI thread and you won't even realize there is such a thing as disk or network IO.

Mouse, keyboard, screen. Those are the things that should run at high priority. Everything else can - quite literally - wait.

> Mouse, keyboard, screen. Those are the things that should run at high priority. Everything else can - quite literally - wait.

I might add audio to this list.

Ah yes, of course. Sorry, I wasn't thinking clearly, just had the usual UI loop and regular interaction with a computer in mind, you are 100% right, audio should have a very high priority. Nothing more annoying than dropouts. Incidentally, the way most OSs deal with that is by having very large audio buffers which in turn will give you terrible latency. On a hard real time OS you could reduce the size of those buffers quite a bit because you can guarantee they are filled (and emptied) regularly.

This is not straightforwardly true. Using small buffers and real-time scheduling works, but it gives terrible power efficiency on a modern high-performance CPU. What you actually want is a scheme with large buffers that can throw out those buffers if something requiring low latency happens.

A lot of usecases require the audio to be low latency all the time. And I don't just mean professional recording studios or musicians, super mainstream things like gaming (especially VR) are way more immersive with low latency audio.

And video conferencing also gets a lot easier, echo cancellation is so hard when you have a lot of data in flight because you will have to do auto correlation on a much larger amount of data.

Video conferencing also fundamentally wants low latency.

Listening to music, on the other hand, does not require low latency except in response to user input.

Well, consider search-as-you-type - you're typing, this goes into some kind of a query into a database. How should the whole UI react ? Display entered text, without updating search results ? Reflow it with best match when results arrive ?

Those are two different processes. The display of the field should be high priority, the lookup should be at least one priority lower.