This is a ridiculous definition of “real-time”. To accomplish this you’d need to subvert the kernal’s scheduler, otherwise you’ll always end up with “unbounded” response times since a single program can’t control what else is running or which clock cycles are allocated to it. What you end up with is an OS that only runs one process per thread.
I’m tempted to abandon using Windows, macOS and Linux as the main platforms with which I interact.
Yeah, okay buddy. And I’m tempted to stop eating and sleeping because I’d like the extra free time.
This is a ridiculous definition of “real-time”. To accomplish this you’d need to subvert the kernal’s scheduler (…)
You missed the whole point of the article.
It makes no sense to read the article and arrive at the conclusion that “I need to subvert the Kernel’s scheduler”. The whole point of the real-time analogy is that handlers have a hard constraint on the time budget allocated to execute each handler. If your handler is within budget them it’s perfectly reasonable to run on the UI thread. If your handler exceeds the budget then user experience starts to suffer, and you need to rework your implementation to run stuff async.
Keep in mind that each mouse click/hover/move/sneeze triggers a handler on GUI applications. Clicking on a button can trigger small, instant changes like updating UI, or can trigger expensive operations like running an expensive task. Some handlers start off as doing small UI updates but end up doing more and more stuff that ultimately start to become noticeable.
The article is not talking about async processing. It’s talking about the process scheduler and thread blocking. It even has a section titled “Real-time Scheduling” that talks specifically about the process scheduler.
It’s simply not possible to fit the author’s definition of real-time without using something like an RTOS, and the author seems to understand that. The main feature of an RTOS is a different scheduler implementation that can guarantee cpu time to events. The catch is that an RTOS isn’t going to handle general purpose usecases like a personal computer very well since it requires purpose-built programs and won’t be great at juggling a lot of different processes at the same time.
The article is not talking about async processing. It’s talking about the process scheduler and thread blocking.
No, not really.
The article doesn’t even cover process scheduling at all. The whole point of the article, which is immediately obvious to anyone who ever worked on a GUI, is what code runs on event handlers and how doing too much in them has a noticeable detrimental impact on user experience (i.e., blocks the main thread).
It’s also obvious to anyone who ever worked on a GUI that you free the main thread of these problems by refactoring the application to run some or all code in a problematic handler asynchronously.
Interesting points, I’ve definitely run into memory constraints which resulted in completely unresponsive hosts a few times over the years. But as the author said, I don’t see this changing within any another of time due to the large scale archetectural changes required… The author also mentioned “I’m tempted to abandon using Windows, macOS and Linux as the main platforms with which I interact.”. Does anyone know which “daily driver” compatible operating system the author could be referring to?
Interesting viewpoint, but I think the applications aren’t at fault: The operating system should ensure that the user has control of the computer at all times. I think you need to do three things to achieve that:
- Limit process RAM usage, so the system never has to swap
- Limit process CPU usage, so the system never stalls
- When drivers / the operating itself crash, revert into a usable state (this one is probably the most complex one)
Interesting viewpoint, but I think the applications aren’t at fault: The operating system should ensure that the user has control of the computer at all times.
The whole point us that the OS does ensure that the user has control of the computer, at least as far as a time-sharing system goes. The problem is that the user (or the software they run) often runs code on the main thread that blocks it.
The real-time mentality towards constraints on how much can be executed by a handler is critical to avoid these issues, and it should drive the decision on whether to keep running a handler on the main thread or get it to trigger an async call.
It is somewhat baffling that most interactive, consumer-facing operating systems are not real-time. I suppose that it’s a product of legacy and technical debt.
Apple did announce that they’re using an RTOS in the Vision Pro. Maybe the VR/AR space will make this more common, since the latency requirements are more stringent.
@verdare @lysdexic they are, but you have to be an enterprise customer.
https://ubuntu.com/blog/real-time-ubuntu-is-now-generally-available
https://learn.microsoft.com/en-us/windows/iot/iot-enterprise/soft-real-time/soft-real-time
RTOS are not going to become consumer operating systems, because there’s too much value in selling it as a capability to enterprise customers (who are largely the consumers who REQUIRE a RTOS, rather than it merely being a convenience).
How can it be convenient for the desktop user to severely limit the amount or running processes? Desktop usage scenarios are the opposite of RT usage.
