I assume it means the user input handler is given a deterministic time slot to do stuff. Regardless of what the operating system is doing, it will always schedule mouse movement (or something along those lines). It's a software implementation (scheduling), but it requires hardware that can support it - usually you need fine-grain control over interrupts. So typically nowadays you see RTOSes on microcontrollers (eg ARM). Maybe more precisely you need access to that fine grain control and that often means getting hold of datasheets that are under strict NDA (eg Broadcom).

RTOSes are often found in autopilot and vehicle management systems controlling critical peripherals or safety critical software. More mundanely there are also sensors that will get upset if you don't give them undivided attention for fixed periods of time (or if you interrupt them, they will terminate the transfer). Image sensors are particularly picky about this.

You can implement hard real-time scheduling using polling instead of interrupts, which is usually faster anyway. It just changes how you measure your tolerance, since nothing is instantaneous, ever.

Yep, more that actually being able to turn interrupts off is a barrier to doing real time work on desktop OS's, for example. Even if you can disable them globally (I think on the Pi you can with some low level C), but stuff goes wonky quickly e.g. if the WiFi soc doesn't get serviced.

It's a good lesson to play with polling versus interrupts on a micro. Susprising just how many cycles it takes to jump into the ISR.

This! Automotive hard real time is polling based.

I think most things are trending that direction, even in soft/non real-time. How fast can an interrupt respond these days anyway, a dozen microseconds?

Nanoseconds if you can respond inside the interrupt handler ('top half' in Linux.) Microseconds to milliseconds with significant variability if you need to be scheduled ('bottom half'.)

And that only if your codepath is deterministic. Linux can do pretty funny stuff at times.

I've run a plasma cutter under Linux on a run-of-the-mill VIA SBC, it was actually pretty easy: just make a program setuid root, use that to disable interrupts after you've read all your data in and then just go wild on polled and precision timed IO until you're done. Re-enable interrupts and return as if nothing ever happened.

It has to do with the architecture of operating system. Real-time operating systems prioritize and preempt tasks based on their priority value - no matter how inefficient it may be; whereas operating systems such as Windows and Linux try to optimize throughput and speed over event based priorities.

More to read here: https://stackoverflow.com/questions/5452371/why-isnt-every-o...

Low latency > high throughput in a real time context.