[jacquesm]

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.

[kjs3]

Would you have that OS you wrote up on github or anything, would you? Big fan of QNX; like to look at OS code.

[jacquesm]

Ok. see https://jacquesmattheij.com/task.cc

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.

[kjs3]

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.

[jacquesm]

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.

[mjcohen]

About as good as the Amiga.

[YarickR2]

And what about IO ? What will you do when everything is stuck waiting for that spinning rust to position itself under the drive head ?

[jacquesm]

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.

[leguminous]

> 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.

[jacquesm]

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.

[amluto]

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.

[snovv_crash]

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.

[YarickR2]

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 ?

[jacquesm]

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