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.
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.
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.