Hacker News Reader

Comment by Ruddle | Hacker News Reader

Author here. Scheduling is a spectrum. Current OS are preemptive, but also a bit cooperative. An app can make the decision of yielding control.

The opposite could work: OS is cooperative, unless some threshold of resource usage is triggered (a timer interrupt of instance). It then context switch to enter a, hopefully rare, failure mode, thus turning preemptive. Kill the app, and get back into cooperative mode. Let's call it optimistically cooperative & pessimistically preemptive.

View on HN

If you're serious about this: make it preemptive. Handle interrupts in the kernel and find a nice way to pass them on to user processes. Any kind of prioritization mechanism will require preemption. I've written an experimental OS myself and I know this is hard stuff but if you can't crack that this is likely to be DOA. If you just want to play around then that's fine of course, there is nothing to stop you from doing that but if you want to see any kind of external adoption it is more or less a must.

Also: this is more like a multi-threaded app itself than an actual OS, for it to be a proper operating system you'd expect at a minimum memory barriers between applications. In that sense the bar for what an OS is has been raised quite a bit since the times of CP/M where it was more of a 'handy library to do some I/O for me' (on mainframes and mini computers there were already proper operating systems back then but on micro computers we had to wait until OS/9 to have something similar).

> I've written an experimental OS myself

What was it called? Do you have more details?

It was called 'Unite', some of the details: QnX clone for x86/32 which at the time wasn't available (nor would Quantum commit to releasing something like that). Pre-emptive multi-tasking, multi-user micro kernel based on the QnX API calls. It worked quite well, we built a bunch of devices that used it internally as the firmware (mostly: internet bandwidth management in the context of a hosting facility). Some HN'er has been trying to revive it in a virtual environment.

Sounds interesting. Thanks for sharing!

You're welcome. One of these days I should try to revive it myself, it's been decades since I last worked on the code though. But I still have the installation media that I made (floppy images) so it should be possible to bring it back to life.

> some threshold of resource usage is triggered (a timer interrupt of instance)

That's literally the definition of preemptive scheduling.

No idea why you are downvoted for quoting the literal textbook definition.

Yes, but "preemptive" sounds so aggressive. We prefer the term "alternative cooperation".

It could also be cooperative scheduling with a watchdog with task killing abilities (like we have for memory usage, it's effectively cooperative + OOM)

Reply on news.ycombinator.com