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

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

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.

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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

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.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

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.