Path: utzoo!attcan!uunet!lts!amanda From: amanda@lts.UUCP (Amanda Walker) Newsgroups: comp.sys.mac Subject: Re: multitasking and IPC (was: System 8.0: no more DA's.) Message-ID: <747@lts.UUCP> Date: 23 Dec 88 17:10:44 GMT References: <1988Dec16.191309.21623@cs.rochester.edu> <326@internal.Apple.COM> <807@esl.UUCP> Reply-To: amanda@lts.UUCP (Amanda Walker) Organization: InterCon Systems Corporation, Reston, VA Lines: 102 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.