Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!lavaca.uh.edu!menudo.uh.edu!sugar!peter From: peter@sugar.hackercorp.com (Peter da Silva) Newsgroups: comp.sys.amiga.advocacy Subject: Re: Single user OS schedulers (Was Re: How do we change the scheduler?) Message-ID: <7661@sugar.hackercorp.com> Date: 30 Jan 91 12:45:19 GMT References: <1991Jan23.213736.28220@Neon.Stanford.EDU> <1991Jan24.152931.1325@NCoast.ORG> <1991Jan25.073516.29644@Neon.Stanford.EDU> <1991Jan26.035750.11786@NCoast.ORG> <1991Jan27.014242.2863@Neon.Stanford.EDU> Reply-To: peter@sugar.hackercorp.com (Peter da Silva) Organization: Sugar Land Unix - Houston Lines: 57 In article <1991Jan27.014242.2863@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: > convenient thing to do everytime you switch programs), why not build > such dynamic priority changing into the OS? Because it doesn't do what you think it does. It adds considerably to the complexity of the scheduler, to boot. When I'm running a WP program, there are lots of tasks "currently active": the keyboard handler, the mouse handler, the input handler, Intuition, the disk drivers and the file system if I'm reading or writing files. Which of these should be boosted in priority? > But it IS the OS's [duty|right|job] to be as transparent to the user > as possible. If the OS causes my interaction with the computer to be > difficult (because of slow response), then it's interfering with what > I want to do (remember, this is restricted to a single user system) But it doesn't. In the general case programs just don't interfere with each other to cause slow or jerky response. > How many of you would prefer the application you're interacting with > in the foreground to be jerky, in return for your background ray > tracer or compile getting a few extra timeslices? None, that's why you run your background task at a lower priority. The thing you have to realise is that there isn't any formal "background task". A task is foreground or background purely in the mind of the user. And how long it is since the user touched that tasks window isn't an accurate guide. > Doesn't this provide some wonderful opportunities for "nuisance > type" programs, which set themselves up to run at a priority of say > 10, and then go into a compute intensive loop? Sure. But in a single user system with no protection mechanism there's no way to keep a program from doing bad things. Even systems like OS/2 will freely let any program slip into supervisor state and break stuff. If you want to protect against malicious programmers you need to go all the way to multiuser protection with security and all that stuff. Maybe you want to, but it's sure the Mac doesn't have it. > Even if I run a raytracer at priority -1, and then another compute > bound task, (say calculating Pi at priority 0), then the raytracer > will starve... Don't *do* that then. Really. If you reformat your hard disk while it's in use bad things will happen, too. > Yes, but that is the hard part :-). Their problem was not with the > mechanics of syncronisation, it was with the logic. It's a simple > fact of life that multi-threaded applications are harder to > write/debug than single threaded apps. It is? Why, pray tell? certainly apps that have to emulate multithreading without support are the hardest of all... -- Peter da Silva. `-_-' .