Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!Larry.Rosenstein From: Larry.Rosenstein@Apple.COM Newsgroups: comp.sys.amiga.advocacy Subject: Re: How do we change the scheduler? (Was Re: Multitasking at home...) Message-ID: <11751@goofy.Apple.COM> Date: 16 Jan 91 22:36:38 GMT References: <1991Jan14.221532.4431@cunixf.cc.columbia.edu> <11719@goofy.Apple.COM> <1991Jan16.015035.10356@zorch.SF-Bay.ORG> Sender: usenet@Apple.COM Lines: 33 In article <1991Jan16.015035.10356@zorch.SF-Bay.ORG>, xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: > > (Larry Rosenstein) at googy.apple.com writes: > > > Not true. For most applications, there is nothing special you have to > > do in order to yield the CPU. It is a normal part of processing user > > input. > > Bzzzzt! Wrong answer, but thank you for playing our game. Have you ever written a Mac application? Most application do not have to do anything special to multitask under MultiFinder. > Pausing for i/o is a separate consideration; the "cooperation" required > for cooperative multitasking is built into the OS i/o routines. Which means it isn't something the programmer has to worry about. > for i/o _is_ cooperating. It is the case of a routine that goes CPU > bound and doesn't bother to give back to the OS the chance to allow > another task to execute that differentiates cooperative from preemptive > multitasking. No argument here. But most applications are user-input bound, not CPU bound. > For example, a Mandelbrot generator or Ray Tracer that draws to the > screen (potentially for hours) and doesn't have a "hey, OS, you need > some time?" at the top of some loop, locks up the machine completely in a This is a case where you have to explicitly yield the CPU. It's an extra burden on the programmers, but it's not especially difficult to do this. I've done this for DBW Render and for the PBMPLUS utilities. Both packages run in the background under MultiFinder.