🚀 go-pugleaf

dml@esl.UUCP (Denis Lynch) replies to goldman@Apple.COM (Phil Goldman):
    >>    ... 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.
    [...]  If they [application developers] 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.

Sigh.  Repeat after me: the Macintosh OS is not a conventional
programming environment.  The Macintosh OS is not a conventional
programming environment.

Now, we argue about whether or not it "should" be until we turn blue in
the face.  If you have an application that truly doesn't fit on a
Macintosh, then use another machine.  However, if you want to write
something that works well on the Macintosh, then it's *your*
responsibility to do it right.  Contrary to popular belief :-), Apple
really doesn't have Thought Police, but they do have user interface
and programming guidelines for a reason, and that reason is simply that
if an application does not follow at least a minimum of them, it won't
work well.

The first and greatest commandment of programming the Macintosh is
Thou Shalt Not Strangle Thy User's Machine.  Don't do things with a
simple command/execute/response metaphor.  Ideally, the user should
*never* see a watch cursor or have to sit locked out of the machine
while something is going on.  Any lengthy operation can be
partitioned in a way that can be done incrementally.  Any iteration
can be expressed as a state machine.  It's not even particularly harder
to code.  I'm even just talking within one application, here.  Part of
Phil's point is that with a "properly" behaved application,
MultiFinder works fine already.  Really.  It's even fairly nice about
it... if an application decides it deserves a stranglehold on the
machine, MultiFinder obliges.  This may be annoying, but I wouldn't
say it's really Apple's fault.

    In any case, it is almost impossible to guarantee that no stretch
    of CPU usage can ever be above some magic threshold.

To use a time-honored Usenet phrase,"Oh, horse puckey." :-).

You may not be used to it, but that doesn't make it "almost
impossible."

    >> o I've also noticed that tasks that put up dialog boxes also
    >>inhibit my switching tasks from multifinder. Lose, lose.

Modal dialogs are generally a loss anyway.  Alerts aren't bad,
since they are by nature very transient, but the only modal dialog
that should be really "necessary" is the Standard File dialogs, and
MultiFinder even gets around one of them. (Aside to Phil: Thank you
for the "tell a running application to open this file" feature in
MultiFinder 6.0!)

    >>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.

See, this is where we disagree.  From the very start, Macintosh
applications have been supposed to be interruptible.  This has little
to do with multitasking--it just made MultiFinder possible in the
first place.

    >The point is, that it *is* the application
    >writer's decision, not the OS's.  The OS provides the mechanism only, not
    >the policy.

Phile seems to agree here...

    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.

No, your argument misses the point.  It's precisely those
"user-interaction-free" computations that should be
interruptible/restartable/suspendable/whatever, and this is a separate
issue from preemptive multitasking.

    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 user should always, always, always be in control of the input
focus.  If an application doesn't allow this, it's buggy.

Sigh.  Now, I am looking forward to the day of pre-emptive
multitasking and intertask memory protection (esp. the latter), because
buggy programs do exist, and since most Mac programmers try to map the
Macintosh environment to a conventional one, not all of them are
recognized as buggy by their creators.

Programming the Mac is like driving a Porsche: great performance,
but it takes more work than driving a Buick.  This is not a design
flaw :-).

-- 
Amanda Walker			...!uunet!lts!amanda / lts!amanda@uunet.uu.net
			  InterCon, 11732 Bowman Green Drive, Reston, VA 22090
--							 Phone: (703) 435-8170
UNIX: the only operating system that can be destroyed by mail.