3 ms·

> Applications controlled multitasking. The apps would signal to Windows that they were sitting idle and another app could take over. Wait a minute, you're say

• jraph 1y ago
  Not exactly, and kinda but definitely not at the same level. Having to trust that random apps behave is very uncomfortable. If some bug makes an app enter an infinite loop, it's a freeze and you are good for a reboot. So we went to preemptive multitasking and we never went back to cooperative multitasking. Inside an app written by one entity, why not? We have all the tools needed to manage apps that froze, restarting apps might be less of a big deal, and there is not necessarily the need for competing things inside an app. To the exception of the GUI, which should remain responsive, so either (1) you make sure computations are always imperceptibly short, or… (2) you are back to a dedicated thread for the GUI, handled with the preemptive multitasking capabilities of the OS. Web apps and Javascript have been more or less (1), but workers have been introduced to have (2), because (1) is quite limited. So, even there, cooperative multitasking has its limits.
• qubex 1y ago
  You’re projecting a ‘modern’ concept onto a bygone time. Applications could (and in unfortunate cases, would) monopolise the system and if they got themselves stuck in a loop they’d never relinquish control of system resources back to the operating system. Your system would freeze or you’d get a blue screen of death. You can call it wait/async if you really want, but it’s hugely misleading in the present context of the term. It was a more fragile system, not a more robust one.