thewrongchristian wrote:
jamesread wrote:
I don't have everything clear in my mind about what I am about to suggest but basically it goes as follows. The OS should avoid context switching by having one single process run with a global event loop. New programs could be added to the system by integrating into this global event loop.
We've
tried this before.
The results weren't pretty.
It's been tried in a number of systems, mostly older ones such as the aforementioned Windows 1.0. The last serious instance of a polling cooperative multitasking system I am aware of was
Oberon, which relied on the compiler for
the language of the same name to ensure that processes released the CPU periodically.
Note that the system
required a compliant compiler designed specifically to insert yields into the code at periodic intervals, otherwise a program could simply never yield and potentially lock the system up, or at the least lock out any other processes (including the kernel itself). This, however, was due to the absence of
any interrupts in the OS, and indeed the
Ceres workstation it was originally implemented on had no usable interrupts of any sort (though the underlying
NS 32000 CPU supported them, the workstation itself didn't have any interrupt controllers).
But even with a clock or timer interrupt to force the system into the scheduler (that is to say, preemption), a single primary system-wide event loop leads to a number of problems. First off, in a modern multi-core system, it means either using only a single core, or else having the separate cores operate entirely separately - which would lock you out of most forms of IPC.
Second, it means that you would in effect be running everything in System mode (or Supervisor mode, or Ring 0, whatever a given CPU designer calls it). Most of your protection mechanisms are thrown out the window when you do this.
Third, it leads to a potential situation similar to the
Global Interpreter Lock used in some Python implementations - anything that locks out the interrupts and/or fails to yield to the scheduler for an extended period can lock up the whole system.