From: johnsd2@jec323.its.rpi.edu (Daniel Norman Johnson)
Subject: Re: the NeXT option (Was Re: 7.1 vs. OS/2 and Windows NT)
Reply-To: johnsd2@rpi.edu
Organization: Rensselaer Polytechnic Institute, Troy, NY.
Date: Wed, 14 Oct 1992 17:34:42 GMT

In article <ewright.719081702@convex.convex.com>, ewright@convex.com (Edward V. Wright) writes:
|> In <1992Oct10.100046.17536@netcom.com> jazz@netcom.com (David C. Navas) writes:
|> 
|> >In article <ewright.718660745@convex.convex.com> ewright@convex.com (Edward V. Wright) writes:
|> 
|> >And why would I ever need to call Forbid() in the first place?
|> 
|> I already covered that with my previous example -- a paint tool
|> that cannot give smooth performance unless it is guaranteed to
|> get all CPU cycles for the duration of its use.  In fact, I could
|> create an infinite number of examples that require this.

It seems to me like it would be better just to jack your priority
way up, and have some sort of mouse-tracking arrangement so that
the system will remember where teh mouse goes when you are switched out.
This way stuff like background downloads could still get time- the
driver for the device would pre-empt your program when it had some
data to pass on. Or something like that.

|> >I suppose that puts the Unix box in the same class as the Macintosh
|> >multitasking kernel?
|> 
|> No, I would never claim that UNIX's multitasking of realtime,
|> interactive applications is as good as the Mac's.

I'll second that.

|> >Why would I do that?
|> >In reality, a good program makes the GUI-half of its code run at a higher
|> >priority than whatever cycle-soaking CPU-half of it does.  
|> 
|> Exactly.  The program is cooperating with the OS by changing its
|> own priority on the fly.  This is *cooperative* multitasking.

Not by the definition I've heard. More on that in a sec.

|> >"Programs that cooperate" does not imply cooperative-multitasking.  You
|> >are generalizing a term and drawing conclusions from that generalization.
|> >Your generalization is incorrect.
|> 
|> "Cooperative multitasking" is distinguished from "preemptive multitasking,"
|> in which the system comes along and hits the program over the head with a
|> hammer whenever the OS figures it's time, with or without the program's
|> cooperation.  This is not the case here.  The programmer must cooperate
|> by not calling Forbid(), or by calling Permit() again after each call
|> to Forbid(), and by cranking his program's priority up only when he
|> really needs to.  This sounds like it's more flexible in the options
|> it gives the programmer, but it's still cooperative.
|> 

The definition I use for co-operative multitasking is a technique for
multitasking where a process can only be switched out if it executes
a call that does this. (such as, say, WaitNextEvent :) ); Its much
easier if you don't have to do this.

Also, there are some cases where it's nice ot be able to pre-empt a
task. Say a program is computing away in the background; it would be
nice to have the system pre-empt that task whenver the user hits a key,
presses a mouse button, whatever, rather than waiting for that task to
yield time. If the task yields often enough everything works fine. But
it's a pain to arrage that. It would be easier not to have to. Even if
you call both arrangements "co-operative", the second is still nicer. (imho)

[deletia- memory partition size vs priority level]

-- 
			- Dan Johnson
And God said "Jeeze, this is dull"... and it *WAS* dull. Genesis 0:0

These opinions have had all identifiying marks removed, and are untraceable.
You'll never know whose they are.
Newsgroups: comp.sys.mac.advocacy