🚀 go-pugleaf

In article <1174@cpocd2.UUCP> howard@cpocd2.UUCP (Howard A. Landman) writes:
>In article <7658@apple.Apple.Com> dwb@apple.UUCP (David W. Berry) writes:
>
>>What I said was that MultiFinder still had some known areas where it
>>could be improved.  Not that it was less than multitasking.  As
>>a matter of fact it is fully and completely multitasking, non-
>>premptive, but multitasking all the same.  Especially when one
>>considers that all macintosh programs should be calling GetNextEvent
>>periodically to interact with the user anyway, and task switching
>>is done there.
>
>You can see the problem but still don't admit it's there?  In real multitasking
>NO SPECIAL CODING IS NEEDED.  Most programs multitask AUTOMATICALLY without any
>special attention from the programmer.
>
>Under MultiFinder, each program (except possibly the last one) must be
>specially coded to be "MultiFinder compatible" by calling WaitNextEvent instead
>of GetNextEvent (if I don't have them reversed).  Why is this a problem?
>Because it only takes one or two programs which fail to do this before
>MultiFinder fails to grant any CPU time at all to the lowest priority task.
>Why is this a problem?  Because there are lots of Mac programs out there which
>were written before MultiFinder and are still useful, but which will never be
>changed.  Companies go out of business.  Shareware authors move on to more
>lucrative pursuits.  Etc.
	Ahh...  But what you're missing is the fact that almost every
application that exists for the Macintosh already periodically calls
GetNextEvent.  Like every time it want's input from the user.  Task switches
are performed on calls to GetNextEvent, WaitNextEvent and, I believe,
EventAvail.  Therefore almost every Macintosh application already allows
task switches at fairly frequent intervals.  No recoding necessary.
No extra work necessary.
	In fact, applications such as Excel already periodically poll
for events during long calculations such as recalculating the spread
sheet to allow the user to scroll to a more useful portion, change more
values, etc, and still have real response.  These applications continue
to work as well or better.
	WaitNextEvent isn't a necessity for task switching.  It's a nicety
which allows a task to more completely specify what kind of tasks it's
interested in.

	A quick summary of pro's and con's of preemptive and nonpreemptive
multitasking:

Task switches:
	With non-preemptive multitasking task switches are simpler
because you know the exact state of the machine when the switch
occurs.  With preemptive you're never quite sure.

Programmer Ignorance:
	With preemptive multitasking the programmer can be completely
ignorant.  He doesn't have to think about the fact that this calculation
is going to take three days and some other task probably ought to run
during that time.

Runaway or inconsiderate programs:
	With nonpreemptive multitasking runaway or inconsiderate programs
can shut a machine down because there's no clean way to get control to
kill them.  With preemptive multitasking they just eat CPU, but they can
probably be cleanly killed.

Indivisible operations:
	Nonpreemptive multitasking makes indivisible operations a snap
because the program is in control of when it let's go of the processor.
With preemptive multitasking you're never sure when the processor will
go away.

Inopportune task switches
	Preemptive multitasking allows task switches at inopportune
times.  Ever have your windowing system lose the processor while your
dragging something around with the mouse, makes for real jerky mouse
movement.

Program control
	Nonpreemptive multitasking gives the program much more precise
control of when it get's switched.

Fairness
	Preemptive multitasking is in general "fairer" in that all
tasks have a more or less equal chance of getting processor time.
This can be modified by priorities, but no one process is going to
get all the processor.  This is desireable in a multiuser timesharing
environment.  It's a much less clear win in a singleuser environment
since it means that tasks that I'm not clearly interested will be
getting a fair share of the processor.

-- 
David W. Berry
dwb@Delphi	dwb@apple.com	973-5168@408.MaBell
Disclaimer: Apple doesn't even know I have an opinion and certainly
	wouldn't want if they did.