I don't see anything on this page
that suggests RDOS is designed for real-time operation, but it does mention "segment protection and paging to provide a stable and secure
system". You're not confusing Leif Ekblad's RDOS with Data General's RDOS, are you?
I'm going by what Leif has said here, namely that the primary use is in embedded control systems. Leif states flat out that:Rewrite from Scratch
My initial design goal was to write an OS that was compatible with MS-DOS, with multithreading and multiprocess support (the "r" in RDOS stands for "realtime DOS").
The primary use case is stated here:Best processor for 32-bit [rd]OS - a.k.a RDOS-OS is best
(I wish I had seen this thread earlier, as it covers quite a lot of what we've discussed here)
Solar, I have 15+ years of experience professional embedded system development for petrol stations, and I know what works and what doesn't, and there is no design limitations in RDOS in this regard. The API mostly was designed during the last 15 years, and adapted to what I regard best practices for such applications. So, the API is the consequence of my experience in the area, not a baggage to overcome. Therefore, I don't need to defend anything.
The limited scope for the system is stated here:OS Graphics
I have no general end-users that can do things like that anyway, so it is out-of-scope for my design.
However, he has stated elsewhere that RDOS is not hard
real-time, something I wasn't certain about until I read this:OdinOS: I'd love some design feedback
At one time I planned to add hard real-time extensions. My idea was to reserve a single core for real-time tasks that would not use preemption, and that would receive no hardware IRQs. In my OS, I use IRQ balancing to even out load, so I regularly change IRQ assignments between cores to achieve even load. This works because many IRQs will schedule a thread on the core the IRQ executes on. Threads are mostly sticky, so if they start executing on one core, they would stay on that core, unless the load balancer moves them to the global thread queue where any core can pick them from. The load balancer works on the time scale of 100s of milliseconds, so moving threads have little effect on performance.
Mind you, had I seen the thread "Your exprience on Segmentation vs. Paging
", and remembered the discussion in "How each process can have same kernel address space?
", I would have known that most if not all of this had been hashed out earlier, rather a critical research failure on my part.