🚀 go-pugleaf

In article <326@internal.Apple.COM> goldman@Apple.COM (Phil Goldman) writes:
>In article <1988Dec16.191309.21623@cs.rochester.edu> miller@ACORN.CS.ROCHESTER.EDU writes:
>>    In article <1988Dec14.223739.16280@cs.rochester.edu> @DOUGHNUT.CS.ROCHESTER.EDU:miller@CS.ROCHESTER.EDU writes:
>>    As an aside to the person asking about TRUE multitasking in 8.0, MultiFinder
>>    already supports true multitasking.  That is, it divvies up CPU time
>>    between multiple applications.  If the reference is to preemptive multitasking,
>>    then there is really no reason to get excited.  Preemptive multitasking
>>    will make life a bit easier on developers, but not much, and have no
>>    typical effect on users.  The only point at which preemptive multitasking is
>>    more useful to a Mac end user is when he is using a buggy app.

This is certainly one of the strangest assertions I have seen lately.
Even if it were true that there was no theoretical benefit to
"preemptive multitasking" there is an obvious practical one:
application developers have only a finite amount of
time/money/patience to expend on a given project. If they have to
spend their time making sure they give swapping a chance in all the
right places, they will either leave out features I value or leave
other bugs in. In any case, it is almost impossible to guarantee that
no stretch of CPU usage can ever be above some magic threshold.

But I also said "even if" there were no theoretical benefit. There is:

>> o I've also noticed that tasks that put up dialog boxes also inhibit my
>>switching tasks from multifinder. Lose, lose. This may be a side effect of
>>the first point; that the application writer doesn't explicitly allow a task
>>switch while asking for input from the dialog box, but on the other hand,
>>making processes interruptible isn't a task for the application writer but
>>for the OS to do, it seems to me. Yet another reason for "preemptive
>>multitasking" to be supported, then.
>>
>
>No.  This is *strictly* a user interface decision.  Modal dialogs are put
>up by the application when it demands the users attention.  Therefore,
>it does not make sense to allow the user to switch, just as he cannot
>do anything else to the machine except respond to the modal dialog.  If
>the app's need is not that pressing it should put up a modeless dialog, or
>use the notification manager.  The point is, that it *is* the application
>writer's decision, not the OS's.  The OS provides the mechanism only, not
>the policy.

But this argument misses the point: for many jobs (recomputing a
spreadsheet, downloading a file, doing a disk backup....) it isn't the
*user* that wants the task switch, but some user-interaction-free
computation. The major flaw in the Multifinder design is just this:
compute switching and user input focus are closely tied together. In
this case, "closely" becomes inextricably.

The Mac OS does many things beatifully, and the Apple team has done a
great job of putting lots of technical capability into a (mainly)
easy-to-use package. This will certainly not continue if Phil's
head-in-the-sand attitude has become typical!

-- 
Denis Lynch                          
ESL Incorporated                         decwrl!borealis!\
ARPA: dml%esl.ESL.COM@ames.arc.nasa.gov    ucbcad!ucbvax!- ames!- esl!dml
SMAIL: dml@esl.ESL.COM                                  lll-lcc!/