From: jazz@netcom.com (David C. Navas)
Subject: Re: the NeXT option (Was Re: 7.1 vs. OS/2 and Windows NT)
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Sat, 10 Oct 1992 10:00:46 GMT

In article <ewright.718660745@convex.convex.com> ewright@convex.com (Edward V. Wright) writes:
>Well, no, you've just proven that the Amiga, like the Macintosh,
>has cooperative multitasking.  The only time it can multitask
>is when an application permits it.  If an application doesn't
>cooperate by using Permit() calls at the appropriate times (after
>a Forbid() call), multitasking can't occur.

And why would I ever need to call Forbid() in the first place?

Any application on ANY platform can misbehave.  "for(;;) fork();".  On Unix
Sys5 machine you can have a realtime task that completely soaks all the
cycles from the machine.  Including the pager ;)

I suppose that puts the Unix box in the same class as the Macintosh
multitasking kernel?

>Who is "you?" Does the user set that priority, or the program?  

Whichever you like.
There are tools on the Amiga which will allow you to allocate, instead of
fixed priorities, a percentage of the CPU.  The Amiga tends to concentrate
on "flexibility" as opposed to "user-friendliness".  Some folks tend to think
that the two are equivalent.  Many more don't.

>If it's the user, it's got to be damned annoying to fiddle with
>the priorities setting everytime you change to a different paint

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.  This way,
the user gets interaction -always- over any CPU-drive program.  Yes,
that puts the burden on the programmer.  Again, there are tools which deal
with these issues.

>on programs cooperating and not just cranking their priority up to
>5 all the time.

"Programs that cooperate" does not imply cooperative-multitasking.  You
are generalizing a term and drawing conclusions from that generalization.
Your generalization is incorrect.

>I'm not sure what this means.  Do you mean you have to set a different
>priority for each paint tool (situation) in your paint program?

Goodness, I hope not!

>I also think you're confusing "customizable" and "friendly."  One

Here I agree with you.

>feature Mac users complain about (justifiably) is having to calculate
>and set appropriate-sized memory partitions for each program. Setting
>priorities is the same thing, applied to CPU cycles instead of RAM
>space.  What makes one friendlier than the other? 

Well, you can still run a program at "unoptimal" priority settings.

>This has nothing to do with multitasking; it's a user interface
>issue.  A modal dialog, by definition, does not allow you to do
>other things while it's open.  That's because a modal dialog box
>is meant for situations that require immediate interaction between
>the application and the user.  If immediate interaction is not
>required, the programmer should use a nonmodal dialog box instead.

Unfortunately, this is a far too frequent mistake of the Mac programs I've
used.

>And, ah, what happens to the Amiga when a programmer fails to
>match up every call to Forbid() with a call to Permit() ?

This is a situation I've never encountered on the Amiga.  More frequent
are mutual deadlock wrt misplaced semaphores.  This freezes your one/two
apps, but not the system.

Now, there are cases of programs that Forbid()/Disable() a bit too much.  For
example, speed testers for the CPU, but then I assume you won't be running
these very often in the background.

On the other hand, I often run "cpp" in the background and am not all that
happy when I can't switch back to the Finder to fix a bug in some distribution
disk at work.

For general usage, I've found the Amiga and the Mac fairly well matched.  I've
got serious complaints for both.  For development I'd take the Amiga over the
Mac anyday.  But that's a completely biased opinion.

-- 
David Navas                                   	jazz@netcom.com
Co-author of: Web Data Acq. and Anal.		dnavas@oracle.com
Upcoming products: Shadow V, Jazzbench 2.0.