Path: 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 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