I worked on a project that used QnX for large volume message transmission via custom telex interfaces. Millions of messages on a good Monday morning. Because I like my development machine to run the same OS as the servers I ended up using it for my daily driver for quite a few years. In the end I liked it so much that when Quantum Software dawdled on their 32 bit implementation that I wrote my own version of the OS.
One really neat demo was 250 windows running the size of poststamps with a little bouncing line demo inside them. All still received their 'fair share' of time, all could still be moved around and expanded as though the machine was otherwise idle.
That's the scheduler. There are a lot of moving parts to running this code, I may make a little project out of restoring it to life under a VM at some point.
Happy reading.
Edit: reading it myself, wow, my English was cringe worthy back then. Moving to Canada certainly fixed that.
Awesome. Thanks. FWIW, I think there's still a place for 32-bit OSes if you never port to 64-bit. Small devices, IoT, or this mc68030 thing I've been building. Lot's of opportunity for fun.
Sure, but if I'm going to spend that much effort I might as well make it future proof. The first iteration of that project cost me two years of my life, and that was when I was 27. To do this again today would be on a relative scale a much bigger investment in the time that remains.
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.
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.
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 ?
