Why is a relocatable stack good for preemptive multitasking?

[drogon]

BitWise wrote:

White Flame wrote:

I can't think of any examples of "real" cooperatively multitasking OSes where a foreground task hogs the CPU busy-polling for input. That's simply not good design, and is an incorrect expectation of cooperative systems.

I seem to remember that in Windows 95/98 all the applications where cooperatively multi-tasked. Only DOS boxes were preemptively scheduled against the GUI tasks.

Nice to have an old thread resurrected every now and then

for preemptive busy looping I'm thinking coroutines which I've used extensively in BCPL in the past and ... RISCOS? (Where IIRC every busy loop had to call back into the GUI dispatcher or something)

-Gordon

[whartung]

White Flame wrote:

I can't think of any examples of "real" cooperatively multitasking OSes where a foreground task hogs the CPU busy-polling for input. That's simply not good design, and is an incorrect expectation of cooperative systems.

This happened routinely on the Macintosh, notably during modal operations like scrolling and such.

Normally, the program would sit on a event queue and handle them independently, and during this phase much of the multitasking occurred. But sometimes during things like scrolling or dragging, the program would take more direct interest in the events to better track the mouse and such.

Pretty sure this was common on early Windows as well.

[BigDumbDinosaur]

BitWise wrote:

White Flame wrote:

I can't think of any examples of "real" cooperatively multitasking OSes where a foreground task hogs the CPU busy-polling for input. That's simply not good design, and is an incorrect expectation of cooperative systems.

I seem to remember that in Windows 95/98 all the applications where cooperatively multi-tasked. Only DOS boxes were preemptively scheduled against the GUI tasks.

Windows 3.11 and earlier ran on top of MS-DOS, which is a real mode, uni-tasking operating system. Windows applications running in that environment were expected to be cooperative. A misbehaving app could, and often did, send the machine into the ditch, frequently corrupting the disk in the process. Those early versions of Windows were especially vulnerable to the insidiousness of memory leaks, especially since all sorts of half-baked code was used to jump past the MS-DOS 640KB wall and make use of extended RAM.

[White Flame]

After re-reading my old post, I was responding to a claim that idle cooperatively multitasking programs sit there pinning the CPU busy-waiting for the next thing to do, which isn't the way things are implemented. Of course cooperative systems can choke, but input polling in specific isn't what does it. Idle cooperative tasks should be just as quiesced as idle preempted tasks, blocked while waiting to be given events.

[Chromatix]

On the Mac, at least, processes are given "idle events" when nothing is happening, allowing them to get useful work done without blocking the user. They must then yield this time regularly by calling the event dispatcher. If they leave the idle event masked (as they have nothing to do), they are simply not called with it. In effect, applications have to poll for events whenever they are busy, rather than when they're idle. Most of the early Mac CPUs were incapable of entering a sleep mode, so if there were no idle-event handlers unmasked in the system, the OS would busy-wait by itself.