Path: utzoo!utgpu!watmath!clyde!ima!bbn!apple!goldman From: goldman@Apple.COM (Phil Goldman) Newsgroups: comp.sys.mac Subject: Re: multitasking and IPC (was: System 8.0: no more DA's.) Message-ID: <326@internal.Apple.COM> Date: 17 Dec 88 22:32:42 GMT References: <1988Dec16.191309.21623@cs.rochester.edu> Organization: Apple Computer Inc, Cupertino, CA Lines: 186 In article <1988Dec16.191309.21623@cs.rochester.edu> miller@ACORN.CS.ROCHESTER.EDU writes: >From: Brad Miller > > Date: 15 Dec 88 20:18:09 GMT > From: goldman@Apple.COM (Phil Goldman) > > In article <1988Dec14.223739.16280@cs.rochester.edu> @DOUGHNUT.CS.ROCHESTER.EDU:miller@CS.ROCHESTER.EDU writes: > >It's something of a pity multifinder doesn't already do this; one could have > >a reasonable yet small IPC standard based on pointers to heap objects... and > >then consumers of a stream could run simultaneously with the producer, > >rather than the current braindamage of producing a file, switching to the > >next program, reading the file... > > This has nothing to do with whether the multitasking is preemptive or not. > In fact, doing producer/consumer on shared memory *is* possible with > MultiFinder. It is absolutely not necessary to do IPC thru files. > >Correct; I was inferring something about the implementation from the current >behavior of multifinder, which was apparently a bad thing to do. (I also did >not mean to imply that "preemptive mutitasking" isn't possible on the 68000; >you simply cannot interrupt in the middle of an instruction the way a page >fault might. One can certainly cause a task switch between arbitrary >instructions. In fact there is no reason the 68000 can't also support memory >management on a more primitive level than demand paging, e.g. swapping. >Since I suspect most owners of SE class or better machines (and probably a >lot of Plus owners as well: I have 90megs) have a hard disk, swapping may >well be a feasible and desirable next step for system development.) > Code swapping is already available via the segment loader. Data swapping is available already via the memory handle and purgeable blocks. Neither are transparent to the app, however. >I discuss true multitasking further below. > > It is true that Apple is not yet officially supporting a full-blown > IPC mechanism, but there are numerous ways to do it already anyway. > >Umm, yes, if the interface for multitasking were better... How do I, for >instance, set up a new type of event, and *sleep* until it occurs? >(additionally, some other process will post the event...) Sure, I can set up >a monitor and have each process run the monitor to check if the event has >occured, but this is a major waste of cycles. I shouldn't get scheduled >unless I have something to do. > If you use _WaitNextEvent, you will sleep until there is an event that you need to process. > 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. > > -Phil Goldman > Apple Computer > >Preemptive multitasking, if I understand what you are referring to, is a big >win for everyone because (for one) it means applications developed for >pre-multifinder macintoshs (or applications that aren't written specifically >with multitasking in mind) will happly coexist with multifinder >applications. That is, since they will get switched out whether they request >it or not, the system will seem a lot more reponsive. Not quite. The whole point is that we are talking about Mac programs here, and Mac programs are *event driven*. This is the point a few people on the net don't seem to understand. "Pre-MF" programs *do* work with MF just fine because they must process events on a timely basis to remain responsive to the user. I don't at all claim that preemptive multitasking is not more useful than cooperative multitasking, as Mr. Roarke (sp?) implies. What I do claim is that it is not much more useful for *Mac programs*, and thus for Mac end users. >Further, given a >reasonable scheduler, the user can set priorities, etc. allowing compute >intesive tasks to run at a lower priority than highly interactive tasks. >(the system can also do this automatically with some idea of quantums). > Perhaps the power user could set priorities, but no one's mom will. Ideally, the system should just handle this correctly. >We both agree that it is a big win for developers too, though I think to be >useful it has some implications for the UI. The main thing is that the >developer shouldn't have to worry about making his process multitaskable, >and right now he does. > Again, the developer does not have to worry in most cases, as the multitasking comes for free in the event driven model. You are correct though that there might be times when the app goes off and does a long task that it is necessary to explicit worry about multitasking, but even there it is fairly simple to deal with. >I have some difficulty understanding the claim that multifinder already >supports true multitasking: > > o As far as I can tell there is no way to put a process to sleep until some > event happens. Further, since most processes are already written to use > non-waiting i/o it isn't easy to just change the non-waiting i/o calls to > waiting i/o calls. Yet clearly code of the form > > (let ((event (get-event MASK))) > (loop (if event > (proccess-event event) > (let-das-run)) ; really allow-procees-switch anymore... > (setq event (get-event MASK)))) > >or it's equivalent in your favorite language is very inefficient; tasks must >be switched to to do nothing more than find out they have no event to >process. two task switches (at least) are wasted in this fashon. > See comments above on _WaitNextEvent > o Further, synchronous i/o, like to the disk, do not seem to enable a task >switch; at least by experimentation under release 6.0 I could not get >multifinder to switch tasks while finder was copying a file, or even while >an application was reading a file. While I can understand (though still >consider faulty) why certain systems, e.g. lisp machines, do not allow a >reschedule during a page fault, there isn't any excuse not to task switch >during disk i/o. Disks are slow. Processes are fast. > There is no big win currently in switching on IO because SCSI DMA is not really in vogue on the Mac yet. Of course, DMA is available for other IO such as, I believe, EtherTalk. However, most of the benefit you wish for can be realized if apps do async IO. The only reason you cannot switch out of the Finder during file copy is that the Finder runs in such a small partition that it swaps out its event handling segment during the copy and thus cannot be switched. Other apps can switch during copies (e.g. MPW 3.0). >This may be a side effect of mouse/keyboard handling; unless your mouse and >or keyboard is controlled by a separate process, a lot of the nice side >effects of multitasking are wasted; I can't conveniently switch forground >tasks or queue information for multiple tasks at one time. (since mouse >movement occured during the disk activity, I presume only clicks were being >ignored?) > This does work, if I understand what you are saying. Click ahead between apps and notice that you will still switch to each one. > 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. >Now this does not mean that there isn't low level support for multitasking, >just that given the above points, it's well hidden from the user. As it should be. >At any rate, while I have years of experience hacking OS kernels, my mac >experience is limited to about a month now. I'd love to be corrected on any >misunderstandings in my assumptions above. I think that everything you say has merit in most computing environments. However, the Mac w/ MF is an entirely different beast. It has two very large differences from other systems: it must remain compatible with software (including the ROM!) designed for a single-tasking machine, and it is driven by a user interface designed for hiding the innards of the machine completely beneath the desktop metaphor. -Phil Goldman Apple Computer