Comment on Most UI Applications are Broken Real-time Applications
lysdexic@programming.dev 1 year agoThis 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.
Vent@lemm.ee 1 year ago
The article is not talking about async processing. It’s talking about the process scheduler. 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.
lysdexic@programming.dev 1 year ago
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.