this post was submitted on 21 Sep 2023
20 points (81.2% liked)

Programming

17344 readers
406 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] Jummit@lemmy.one 2 points 1 year ago (1 children)

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:

  1. Limit process RAM usage, so the system never has to swap
  2. Limit process CPU usage, so the system never stalls
  3. When drivers / the operating itself crash, revert into a usable state (this one is probably the most complex one)
[–] lysdexic@programming.dev 5 points 1 year ago

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.