4 ms·
Total overkill. If the screen loading is slower than a frame because of... - I/O like file access or networks, you can punt to an async framework like Rust's T
by ReactiveJelly 3y ago
Total overkill. If the screen loading is slower than a frame because of...
- I/O like file access or networks, you can punt to an async framework like Rust's Tokio
- CPU number crunching like cracking a password, you can punt to a worker thread (like Tokio's `spawn_blocking`)
The kernel scheduler is smart enough to give time slices to the UI thread even if the password-cracking thread is trying to eat as much CPU as possible, or, God forbid, the network thread is _sleeping_ until a packet arrives. (Networking is a waste of a thread. Most requests and responses are small enough that the CPU could process them on the UI thread, it's just that sleeping the whole thread until the message shows up is goofy)
It's not a lack of processors, it's the fact that good multi-threading and UI totally changes the architecture of a program, and most of us aren't trained for it or incentivized to implement it.
- RecycledEle 3y agoI disagree that a dedicated I/O processor is overkill. We spend a lot of transistors and code to solve problems that occur very rarely. Obscure race conditions come to mind. Putting the UI in real time would save me hassle every day, so it's worth the effort. Adding USB ports to a video card would achieve 99% of the hardware requirements. The other 1% is made up of things I have overlooked. The software would be more complicated, but it would not require rewriting applications. It would mostly be recoding OSes. Also, the security benefits of linking output the screen to input from the keyboard and mouse in real time would be substantial.