🚀 go-pugleaf

In article <19960205.11A30A0.F4D4@olympus.net>, dons@olympus.net (Don
Schmelling) wrote:

> Because, you are completely uncompromising.
> You just will not admit that when a task is taking up all of the cpu
> time that you are no longer multitasking.

I've admitted it every single time (that you cannot switch to another
high-level "process").  You just won't admit that it isn't a very big
deal, since in practice, it just doesn't come up often enough (less than
once a year on the commercial and shareware stuff 99.99% of us Macintosh
users actually use).

> I am sure that you have had the unfortune to write a program with an
> anfinite loop in it.  If you try to stop the process it does not
> terminate instantly.

Fine.  On average, there will be a 1/120 of a second delay.  Again, who
really cares?

> The issue is that with a PMT system there are not the amounts of
> programmig rules that a CMT system has in order to have effective
multitasking.

Sure there are.  The rules are just different.  In a PMT system, you
cannot query the state of the machine (eg: what is the front most window)
and expect that to be the state of the machine when you use the
information.  You may have to add synchronization directives (eg:
semaphores) around stuff you would never have to do in a CMT system.  It
can be easier to make real-time guarantees (eg: you want to show a
QuickTime movie) with a CMT system than with a PMT system, especially when
you don't know ahead of time exactly how much CPU time you'll need.  Yes,
you can up the priority of a PMT task so that nothing else can preempt it,
but all that is doing is turning that process into something that has to
cooperate in order to let the rest of the system multitask.  PMT is a
tradeoff, not a panacea.
-- 
        Nevin ":-)" Liber       nevin@CS.Arizona.EDU    (520) 293-2799