🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.mac
Article #35816

Re: multitasking and IPC (was: System 8.0: no more DA's.)

#35816
From: 3929] Brian Gilstrap
Date: Mon, 26 Dec 1988 19:53
211 lines
12011 bytes
Just figured it was time to put in my $0.02 worth.  A disclaimer up front:
Amanda Walker seems like a pretty rational and calm person.  I'm not trying
to flame him/her (I make no assumptions simply because I don't want to 
accidentally offend).  This is actually a response to this whole thread of
thought which I have been following for some time now.  So Amanda, please
don't take it directly, it's general.



In article <747@lts.UUCP> amanda@lts.UUCP (Amanda Walker) writes:
>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.

It's my responsibility to do it right?  This sort of attitude is what can
kill the Mac.  Geez!  Let's face it.  The Mac is fighting a severe uphill
battle to get into corporate markets (at least in the U.S.).  Whether you
like it or not, Apple *needs* to get into the corporate world (at least
in a lot of peoples' opinions) in order to simply keep existing and improving
their products.

I love the Mac.  It's a slick, snazzy, snappy, wonderful environment.  BUT,
the number of programmers who are willing to spend HUNDREDS to perhaps
THOUSANDS of hours learning how to program it in accordance with Apple's
definition of "correct" is rather small.  I admit that those numbers are growing
(greed will do a lot :-).  But in all the cases I've seen, the primary reason
that a programmer didn't want to program the Mac is "it's got this bizaaro
operating system...".  I've found it very hard to convince *myself* to learn to
program the Mac.  I *hate* having to learn *any* vendor's proprietary OS.

There have been a lot of things developed in the world of programming which are
very useful, but which require pre-emptive behavior.  You're telling me I need
to entirely redesign these for the Mac?  If I'm joe average programmer I'll
probably tell you to go shove it and start writing things for Windows and the
PC or PM & PS2 machines.  &^$%#, *I'm* a major Mac advocate here at work, and I
have a *very* hard time justifying the snobbish attitude of many who've found
the "Mac religion".  I'm even beginning to get turned off myself.

Don't get me wrong.  You have every right to feel the Mac is better than sliced
bread.  I would tend to agree with you.  But if you want new and slick programs
to come out on the mac, don't force programmers to rewrite everything they've
worked on.  And please don't tell me that all the really neat new stuff is
coming out on the Mac, we both know better.  Actually, I guess it depends upon
your definition of "new new stuff".  If you define it to be "It fits the Mac
approach", the yes, it's all coming out on the Mac first (or almost all).  But
that's a pretty recursive definition there...

The Mac is not the primary source of programmatic research and innovation; the
academic and research worlds *are*.  I know that there is still a lot of neat,
creative thought going on in garages and bedrooms (I hope I'm doing some
myself), but that's not where the brunt of it is happening.  If we want these
advances to come to the Mac machines in a timely fashion, we need to provide
an environment which makes porting to the Mac simple.  Certainly, if things turn
out to be *very* usefull, then some Mac-ite will write a version for the Mac.
But that leaves things very much to chance and will generally make for slow
migrations to/from the Mac OS world.

>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."
>
Only if you redesign your algorithm so that it always makes sure to not take
too much time.  [Suppose I'm a CAD manufacturer]  "You want me to redesign my
much > 10,000 line system?!?".  Right.  When I've got plenty of time and my
profit margins are solid enough that I can afford to to it.  In the meantime,
I hope you have lots of patience.  [Back to me as me]  Sure, greed and a growing
Mac environment will help this situation.  But wouldn't you like to have the
nifty stuff available to other machines ported to the Mac in a *timely* fashion.

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

Nope.  Why make every programmer be aware of "this is how I allow for
multi-tasking".  That's foolish if you can put it into the OS.  Let's face
it, there will always be programmers who don't follow the guidelines 100%.
I don't want my application and or machine to suffer from that.  If you 
can make pre-emptive-ness transparent (totally) (and you can) then do it!
Don't make *every* program worry about it.  Do it once, in one place, with
one set of code, with one group maintaining it.  Why on earth would you want
to *not* do this?  And I'm not flaming Apple here.  I would imagine they
are working on this right now.  I certainly don't claim that pre-emptive
multi-tasking is trivial to graft onto the current OS.  However, if they don't
do it, I will see it as a disastrous (sp?) lack of vision on their part.

>
>    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.
>
But if your OS can't let you run a download in the background, even though
your machine has the CPU-power to do so, it's a losing proposition.  If your
machine doesn't have the power, then your multi-tasking-ness is pretty much
an illusion anyway so why not go back to switcher?  If the machine can truly
handle multi-tasking, then pre-emption won't hurt it.  If the machine can't
handle it, then Apple is selling us bullsh*t anyway.

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

Let's examine your metaphor.  The only difference in driving a Porsche than
driving a Buick is in physical muscle exertion to use the brakes and turn
the steering wheel.  So, it takes more sweat to get the job done.  Now,
do we really get great performance?  Hmm...we really only get the advantage
of a consistent look'n'feel.  Sort of like having your toilet have similar
switches to your Porsche, eh? :-).  Afraid I don't see much here except for
deterrances to programmers.

By the way, I think even Apple recognizes that they're losing their
"look'n'feel" edge, hence the law suit against Microsoft.

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

That's funny, what about all those hard drives trashed by Appleshare?

And Hmm...let's try that again:
"UNIX: the only operating system which has enough power and flexibility that
someone could write a worm powerfull enough to dynamically move itself from
machine to machine in a heterogeneous environment."
Not necessarily the best use of that power, but a demonstration of it
nonetheless.


Brian R. Gilstrap                     ...!ames!killer!texbell!sw1e!uucibg
                                      ...!bellcore!texbell!sw1e!uucibg
All thoughts and statements are       One Bell Center Rm 17-G-4
my own...my employer wouldn't         St. Louis, MO 63101
even think of thinking them...        (314) 235-3929
Technical Details
Message-ID: <1136@sw1e.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!watmath!clyde!att!osu-cis!killer!texbell!sw1e!uucibg
References: <1988Dec16.191309.21623@cs.rochester.edu> <326@internal.Apple.COM> <807@esl.UUCP> <747@lts.UUCP>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!watmath!clyde!att!osu-cis!killer!texbell!sw1e!uucibg
From: uucibg@sw1e.UUCP (3929] Brian Gilstrap)
Newsgroups: comp.sys.mac
Subject: Re: multitasking and IPC (was: System 8.0: no more DA's.)
Message-ID: <1136@sw1e.UUCP>
Date: 26 Dec 88 19:53:52 GMT
References: <1988Dec16.191309.21623@cs.rochester.edu> <326@internal.Apple.COM> <807@esl.UUCP> <747@lts.UUCP>
Reply-To: uucibg@sw1e.UUCP ([5-3929] Brian Gilstrap)
Organization: Southwestern Bell Telephone Co.
Lines: 211