miller@ACORN.CS.ROCHESTER.EDU (12/17/88)
From: Brad Miller <miller@CS.ROCHESTER.EDU>
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.)
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.
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. 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).
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.
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.
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.
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?)
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.
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 far as
I can tell, I have a foreground process, and my background processes wait
until I'm doing i/o when I can switch to them.
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.
----
Brad Miller U. Rochester Comp Sci Dept.
miller@cs.rochester.edu {...allegra!rochester!miller}goldman@Apple.COM (Phil Goldman) (12/18/88)
In article <1988Dec16.191309.21623@cs.rochester.edu> miller@ACORN.CS.ROCHESTER.EDU writes: >From: Brad Miller <miller@CS.ROCHESTER.EDU> > > 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
sec@berlin.acss.umn.edu (Stephen E. Collins) (12/18/88)
In article <326@internal.Apple.COM>, goldman@Apple.COM (Phil Goldman) writes: > In article <1988Dec16.191309.21623@cs.rochester.edu> miller@ACORN.CS.ROCHESTER.EDU writes: > > In article <1988Dec14.223739.16280@cs.rochester.edu> @DOUGHNUT.CS.ROCHESTER.EDU:miller@CS.ROCHESTER.EDU writes: > 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. Is that a bug or a feature? > > 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 > > 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. If this is the case, then any application that might ever be run under Multifinder should never make use of a Modal Dialog (so just burn 'em out of the ROMS). While an application may frequently require the user's attention before IT can continue, the system, in a MF environment, should ALWAYS be able to continue without requiring the user to attend to ANY individual application, no matter what state that application may be in. You are still thinking in terms of single-tasking. > 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. I've been working on computers for some 15 years, and I can't think of a single system (nor application, for that matter) that didn't have the problem of remaining compatible with previous versions; and that includes many single-tasking vs multitasking evolutions. Furthermore, the Mac user interface is not "entirely different". (ever hear of a company called Xerox?). SUN, HP, and Microsoft come to mind immediately; I'm sure there are others. The problems faced in the evolution of the Mac are not unique to the world of computing. Those at Apple may like to think they are going where no man has gone before, but they would do well to examine and learn from the experiences of others. +-----------------------------------------------------------------------+ | Stephen E. Collins | sec@ux.acss.umn.edu / | ACSS Microcomputer & Workstation Systems Group | sec@UMNACVX.BITNET / | 125 Shepherd Labs +-----------+-------------------/ | University of Minnesota | Cum hanc intellegas, Latinam / | Minneapolis, MN 55455 | sententiolam potes legere! / +------------------------------------+----------------------------+
goldman@Apple.COM (Phil Goldman) (12/19/88)
In article <264@berlin.acss.umn.edu> sec@berlin.acss.umn.edu (Stephen E. Collins) writes: >In article <326@internal.Apple.COM>, goldman@Apple.COM (Phil Goldman) writes: >> In article <1988Dec16.191309.21623@cs.rochester.edu> miller@ACORN.CS.ROCHESTER.EDU writes: >> > In article <1988Dec14.223739.16280@cs.rochester.edu> @DOUGHNUT.CS.ROCHESTER.EDU:miller@CS.ROCHESTER.EDU writes: >> 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. > >Is that a bug or a feature? > A tradeoff. >> > 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 >> >> 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. > >If this is the case, then any application that might ever be run under >Multifinder should never make use of a Modal Dialog (so just burn 'em ^^^^^^^^^^^^MultiFinder >out of the ROMS). While an application may frequently require the >user's attention before IT can continue, the system, in a MF environment, >should ALWAYS be able to continue without requiring the user to >attend to ANY individual application, no matter what state that >application may be in. You are still thinking in terms of single-tasking. > No. This is a user interface decision. I understand your argument, but it does not come down to a single- vs. multitasking decision. Rather, it is a decision on how much power to give to the application. Also, remember that compatibility includes user interface compatibility as well. >> 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. > >I've been working on computers for some 15 years, and I can't think of >a single system (nor application, for that matter) that didn't have >the problem of remaining compatible with previous versions; and that >includes many single-tasking vs multitasking evolutions. > True. Sorry for the hyperbole. However, there are *few* systems with such a large and demanding need for compatibility, caused by the combination of a huge existing application base along with a very rich and complex application model. I'm sure someone more knowledgeable in the field can name a few with both requirements. I can't. >Furthermore, the Mac user interface is not "entirely different". >(ever hear of a company called Xerox?). SUN, HP, and Microsoft >come to mind immediately; I'm sure there are others. > Again, it is the combination of the two that makes the Mac w/MF unique, not merely the user interface. >The problems faced in the evolution of the Mac are not unique to the >world of computing. Those at Apple may like to think they are going >where no man has gone before, but they would do well to examine and >learn from the experiences of others. Like any other computer maker, some of Apple's problems are uniqe, and some are not. I at least would like to think that we do learn from other's experiences, as well as from our own. On that last note, much of the MF interface could be seen many years ago on the Lisa. -Phil Goldman Apple Computer
lipa@polya.Stanford.EDU (William J. Lipa) (12/19/88)
I wonder if it would be possible for Apple to define a routine to let other applications have a time slice which could run at interrupt time. For example, if EventAvail was removed from the list of traps that may move or purge memory, an application writer could install a VBL task which did nothing except call EventAvail 60 times a second. Since EventAvail is (I believe) one of the traps which allows context-switching, this would give programmers an easy way to add preemptive multi-tasking to their applications. Since each application runs in its own heap, it shouldn't have its own memory moved or purged even if another application is run. I suppose you would get into trouble if your app was allocating a block in the system heap, though. Might there be some way around this? Bill Lipa Bitnet: lipa%polya@stanford
shebs@Apple.COM (Stanley Todd Shebs) (12/20/88)
In article <326@internal.Apple.COM> goldman@Apple.COM (Phil Goldman) writes: >[...] 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. I wasn't going to say anything, but this is getting too ridiculous. There is a point at which putting work onto the developer starts losing rather than winning. How many times have I been wedged because some bozo thought that a dialog was *so* *important* that I'm not going to be able to do anything else until I respond, or because some other bozo figures I have nothing better to do than wait for a program to finish some lengthy operation. It doesn't even require an unfriendly application, just some unanticipated situation where a program gets stuck in a loop. It never ceases to amaze how many people will take some expedient decision and make into a "principle" to be held true for all time. Some of the rationales for Mac design decisions are getting uncomfortably reminiscent of IBM's arguments for why their 25-year-old designs are still valid today. Anyway, there are quite a few people at Apple that do believe pre-emptive multitasking is important, that applications should be simpler to write, that memory protection is essential, and that the OS should support true distributed applications. The key question is how to turn all of these (well-known) ideas into new products that retain the advantages of the Mac. stan shebs shebs@apple.com
sbb@esquire.UUCP (Stephen B. Baumgarten) (12/20/88)
In article <329@internal.Apple.COM> goldman@Apple.COM (Phil Goldman) writes: [ About why when an application demands the user's focus of attention with a modal dialog box, the user cannot switch out of the application. ] >No. This is a user interface decision. I understand your argument, but it >does not come down to a single- vs. multitasking decision. Rather, it is >a decision on how much power to give to the application. > >Also, remember that compatibility includes user interface compatibility as well. The time people most want to switch out of an application is when they're faced with an open or save file box and can't remember where they put a file, or want to rename a file, or want to delete a file, etc. And it's at that very point that Apple takes away their ability to switch to the Finder. If you doubt this, look at the number of utilities that help patch the standard open and save dialog boxes (Findswell, HFS Navigator, etc.), and look at how popular they are. People intuitively understand why their work on a particular application (computer and otherwise) must wait until a crucial piece of information is obtained. I'm sure people would be quite confused if they started to open a file, got the standard open box, and then went right back to working on their document, leaving the open dialog box on the screen somewhere. No one has a problem with having an application wait on them to select a file name. But in everyday life people are faced with this situation all the time, and never do they suspend everything else they are doing if they don't have to. For example, I'm writing Christmas cards now. I'm about to mail a letter, but I can't remember my friend's address. So my ability to mail the letter must now wait on a piece of information I don't have at the moment. In real life, I now put my pen down, pick up my address book and look up the address. Or I might just leave it altogether and play a game. Of course, the letter still remains on my desk, unaddressed, and I still can't mail it until I find my friend's address somewhere. On the Mac, I'm stuck. I can't continue in the "mail" application until I have the address, but on the other hand, I can't switch to my Rolodex program to find the address unless I first tell the "mail" program to cancel the "mail it" operation (i.e., dismiss the "save" dialog box). Somewhat counter-intuitive, since canceling the "mail it" operation is exactly what I *don't* want to do. Watch beginning Mac users use MultiFinder. You see them click on the mini-icon in the menu bar to switch applications during opens, during saves, even during a session with the Font/DA Mover. This may be a compatibility issue or there may be technical reasons for it (e.g., the Font/DA Mover might have the System file in an inconsistent state or something), but I don't think it could possibly be a user-interface issue. In fact, the Font/DA Mover is a good example of something that was designed for technical reasons but never intended as an example of a "user-interface" decision. It's a kludge, and people don't understand it or how it works, because its operation is so different than the standard "Finder" style of doing things (Servant really was much better than MultiFinder in this respect). On the other hand, no one at Apple ever justified the Font/DA Mover's existence by claiming that it was designed with user-interface issues in mind. It was just a side-effect of having to work within the severe hardware and software limitations of the original Macintosh (just like the original disk copy program that used screen memory). Sorry I'm going on and on about this, but regardless of whether MultiFinder as it now is is better or worse than pre-emptive multitasking, I think it's worth keeping in mind that users don't like to be "moded-in" any more than they have to be, and that we should therefore be careful before justifying technical hacks (even if they are brilliant, fully-functional hacks) on user-interface grounds. -- Steve Baumgarten | "New York... when civilization falls apart, Davis Polk & Wardwell | remember, we were way ahead of you." cmcl2!esquire!sbb | esquire!sbb@cmcl2.nyu.edu | - David Letterman
dorourke@polyslo.CalPoly.EDU (David M. O'Rourke) (12/21/88)
In article <337@internal.Apple.COM> shebs@Apple.COM (Stanley Todd Shebs) writes: >Anyway, there are quite a few people at Apple that do believe pre-emptive >multitasking is important, that applications should be simpler to write, >that memory protection is essential, and that the OS should support true >distributed applications. The key question is how to turn all of these >(well-known) ideas into new products that retain the advantages of the Mac. Thankyou!!! I'm looking forward to Apple's implementations of MT & VM. Thankyou for your posting and letting us know that Apple is progressing forward and some people at Apple believe they can do better than the current implementation, not saying the current implementation is bad, its just that you can always do better ;-) -- David M. O'Rourke dorourke@polyslo.calpoly.edu "If it doesn't do Windows, then it's not a computer!!!" Disclaimer: I don't represent the school. All opinions are mine!
ts@cup.portal.com (Tim W Smith) (12/21/88)
EtherTalk does not use DMA. The interrupt routine copies the data out of the buffer on the EtherTalk card to the destination. Tim Smith
dml@esl.UUCP (Denis Lynch) (12/22/88)
In article <326@internal.Apple.COM> goldman@Apple.COM (Phil Goldman) writes: >In article <1988Dec16.191309.21623@cs.rochester.edu> miller@ACORN.CS.ROCHESTER.EDU writes: >> In article <1988Dec14.223739.16280@cs.rochester.edu> @DOUGHNUT.CS.ROCHESTER.EDU:miller@CS.ROCHESTER.EDU writes: >> 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. This is certainly one of the strangest assertions I have seen lately. Even if it were true that there was no theoretical benefit to "preemptive multitasking" there is an obvious practical one: application developers have only a finite amount of time/money/patience to expend on a given project. If they 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. In any case, it is almost impossible to guarantee that no stretch of CPU usage can ever be above some magic threshold. But I also said "even if" there were no theoretical benefit. There is: >> 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. 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. 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 Mac OS does many things beatifully, and the Apple team has done a great job of putting lots of technical capability into a (mainly) easy-to-use package. This will certainly not continue if Phil's head-in-the-sand attitude has become typical! -- Denis Lynch ESL Incorporated decwrl!borealis!\ ARPA: dml%esl.ESL.COM@ames.arc.nasa.gov ucbcad!ucbvax!- ames!- esl!dml SMAIL: dml@esl.ESL.COM lll-lcc!/
amanda@lts.UUCP (Amanda Walker) (12/24/88)
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.
barmar@think.COM (Barry Margolin) (12/24/88)
I have one question about this whole issue:
Suppose I'm running a Multifinder-aware terminal emulator, I start a
download, and then switch into another application. I know that the
download works fine so long as the application calls WaitNextEvent
frequently. At some point the application puts up a modal dialogue,
which, as we know, prohibits switching. Question: does it also
prevent the background download from running?
If the download is prevented, too, then I believe this is what someone
was talking about when they said that Apple has inextricably connected
input focus with computation.
Barry Margolin
Thinking Machines Corp.
barmar@think.com
{uunet,harvard}!think!barmarfry@brauer.harvard.edu (David Fry) (12/24/88)
In article <34550@think.UUCP> barmar@kulla.think.com (Barry Margolin) writes: >I have one question about this whole issue: > >Suppose I'm running a Multifinder-aware terminal emulator, I start a >download, and then switch into another application. I know that the >download works fine so long as the application calls WaitNextEvent >frequently. At some point the application puts up a modal dialogue, >which, as we know, prohibits switching. Question: does it also >prevent the background download from running? This doesn't stop the download, since ModalDialog calls {Get,Wait}NextEvent repeatedly. BUT if you hold the mouse down on a menu or scroll bar, the download will be interrupted. This is the feature that I think shows the need for pre-emptive MT most clearly. MultiFinder is super, given what it has to do, but I don't like calling $35/hour telecomm services, and then feeling afraid to scan the menu bar in another application for fear of wasting valuable download money. David Fry fry@huma1.harvard.EDU Department of Mathematics fry@huma1.bitnet Harvard University ...!harvard!huma1!fry Cambridge, MA 02138
oster@dewey.soe.berkeley.edu (David Phillip Oster) (12/25/88)
In article <877@husc6.harvard.edu> fry@brauer.harvard.edu (David Fry) writes: >BUT if you hold the mouse >down on a menu or scroll bar, the download will be >interrupted. This is the feature that I think shows the need >for pre-emptive MT most clearly. MultiFinder is super, given >what it has to do, but I don't like calling $35/hour telecomm >services, and then feeling afraid to scan the menu bar in >another application for fear of wasting valuable download >money. o.) A terminal emulator that behaves this way is buggy! Download/Uploads can be done quite comfortably at interrupt level, all except file i/o, and that can be handled by buffering enough text for a minute or so of mousing around. o.) The Macintosh party line is that the computer must have the perception of speed. Note, this is different from actually being speedy. For example, Bill Atkinson told me that originally MacPaint drew directly to the screen during mouse drags, but this caused flicker. He added off-screen buffering to get rid of the flicker, and discovered that people percieved the new version as running faster, because it was now smooth, when, in fact, it was drawing to the screen less often than the previous version. The Macintosh is multi-tasking. At this moment, I am using Menu Clock, a task I wrote in '85. It has always used the multi-tasking that has always been available. It is just an Apple policy decision that user-interface intensive tasks get >99% of the CPU, while they are running the user-interface. (Only VBLs, sound, and device interrupts run during user-mouse tracking.) The Lisa had multi-tasking, and was percieved as sluggish. The Macintosh development team wanted their machine to seem faster, even though they weren't using the fancy dual-ported RAM the Lisa had. Macintoshs through the MacPlus gave about 30% of their CPU time up so the video controller could get at the video RAM, so an 8MHZ 68000 in a Macintosh actually about the same as the 6MHZ 68000 in the LIsa, when the effect of the dual ported RAM was taken into account. So, the Macintosh team made the rule, while the mouse is down, the user gets the whole CPU. Could you imagine trying to use a paint program, and having a nice freehand line get screwed up because some task ate a lot of CPU time in the middle of the stroke, causing the paint program to miss mouse coordinates? An alternative solution would have been, just throw more hardware in the box. That was the route the Lisa took. Booting an Apple Lisa took $10,000. worth of hardware at a time when booting a Macintosh took only $ 2,500. ----------------------- Most Unix programs ignore the problems of concurrent updates to the same data files from multiple programs running in parallel. For example, one person edits the beginning of a long file, while another person edits the end of that same file. Whoever saves their changes last will wipe out the changes of the other. And it is a hard problem in general, since a "transaction" may involve changes to multiple files: Suppose I want to move something from file A to file B. I read file A, make an in memory copy of the part of interest, write the short file A. XXXX. Now, I open file B, write out the change, and close it. At the time represented by the "XXXX" above, the amount on disk is less than it should be. If a prowler program, say another user of a file-backup utility, looked at both file a and file b at that time, it wouldn't see any trace of the part that is in my local memory. The Unix operating system gurantees that directories can be modified cleanly, and the mail system gurantees that new mail can be delivered while you are reading the old, But the designers of Unix said the problem was too hard to solve in general, so they were leaving it to the application authors. As late as Version 7 of Unix, there was no information in the Unix manuals on writing programs that could safely modify the same file in parallel. How should the Mac handle this problem? One way is to add a new manager: the Database Manager, and have new programs use it instead of the file manager.
leonardr@uxe.cso.uiuc.edu (12/26/88)
oster@dewey.soe.berkeley.edu(David Oster) writes in comp.sys.mac >In article <877@husc6.harvard.edu> fry@brauer.harvard.edu (David Fry) writes: >>BUT if you hold the mouse >>down on a menu or scroll bar, the download will be >>interrupted. This is the feature that I think shows the need >>for pre-emptive MT most clearly. MultiFinder is super, given >>what it has to do, but I don't like calling $35/hour telecomm >>services, and then feeling afraid to scan the menu bar in >>another application for fear of wasting valuable download >>money. > >o.) A terminal emulator that behaves this way is buggy! Download/Uploads >can be done quite comfortably at interrupt level, all except file i/o, and >that can be handled by buffering enough text for a minute or so of mousing >around. > THIS IS NOT ENTIRELY TRUE!! I will agree that at normal communication speeds such as 1200 and 2400 baud, there should be no problem with scanning the menu bar or scrolling - BUT when using higer speeds such as 9600 and 19200, you have a MUCH greater chance of timeout or syncing problems during system actions (MenuSelect, TrackControl, GrowWindow, etc.)! I agree that Pre-emptive MT would solve this problem, but so would rewriting some/all of these toolbox calls to just call GNE/WNE - since most of them operate (I assume, never disassembled them) on some type of 'While StillDown()' loop, putting the GNE/WNE calls in should not disrupt anything but would give background apps the time they needed. +---------------------------------+-----------------------------------+ + + Any thing I say may be taken as + + Leonard Rosenthol + fact, then again you might decide+ + President, LazerWare, inc. + that it really isn't, so you + + + never know, do you?? + + leonardr@uxe.cso.uiuc.edu + + + GEnie: MACgician + MacNET: MACgician + + Delphi: MACgician + AppleLink: D0025 + + + + +---------------------------------+-----------------------------------+
uucibg@sw1e.UUCP (3929] Brian Gilstrap) (12/27/88)
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
kehr@felix.UUCP (Shirley Kehr) (12/28/88)
In article <1136@sw1e.UUCP> uucibg@sw1e.UUCP ([5-3929] Brian Gilstrap) writes: >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. The number of users who are willing to spend HUNDREDS to perhaps THOUSANDS of extra dollars for a Macintosh instead of a PC clone are doing it for a reason. If programs are no different on the two machines, which machine do you think we'll buy? >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. What neat new stuff is that? >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. For the record, if a review of a program notes that it does not follow the Mac interface, I'll look for another product that does. For me it is the Mac interface as practiced by Mac software developers that made me switch to Mac in the first place. For all the word processor wars, there are plenty of them that do what I need. For the same reason that you don't want to learn to program the Mac, I don't want to learn your program. I'm perfectly happy with what I have today. We're not all sitting around waiting for the perfect program; we have work to do and we're going to do it with a minimum of fuss and bother. It would take one heck of a program to get me to switch from Microsoft Word. >Brian R. Gilstrap ...!ames!killer!texbell!sw1e!uucibg Shirley Kehr
dorourke@polyslo.CalPoly.EDU (David M. O'Rourke) (12/29/88)
In article <747@lts.UUCP> amanda@lts.UUCP (Amanda Walker) writes: >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. Yes, I've been programming/teaching Mac programming for two years now and I realize that the Macintosh isn't conventional. But you as a programmer should not have to worry about schedualing your process or someone elses. The event driven nature of programming a Macintosh is independant {or should be} from the task schedualing. >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. I think you're confused :-( >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. No it's not. What is wrong with pre-emptive multi-tasking? All it does is take the current process and suspend it, start a new one, and so on until you're back to the beginning again. Pre-emptive multitasking is a separate issue from the Mac's user interface. I should be able to recalculate a spread sheet in the background with out having to place a wait next event or otherwise every ten lines of code. -- David M. O'Rourke dorourke@polyslo.calpoly.edu "If it doesn't do Windows, then it's not a computer!!!" Disclaimer: I don't represent the school. All opinions are mine!
tim@hoptoad.uucp (Tim Maroney) (12/29/88)
In article <34550@think.UUCP> barmar@kulla.think.com (Barry Margolin) writes: >Suppose I'm running a Multifinder-aware terminal emulator, I start a >download, and then switch into another application. I know that the >download works fine so long as the application calls WaitNextEvent >frequently. At some point the application puts up a modal dialogue, >which, as we know, prohibits switching. Question: does it also >prevent the background download from running? In article <877@husc6.harvard.edu> fry@brauer.harvard.edu (David Fry) writes: >This doesn't stop the download, since ModalDialog calls >{Get,Wait}NextEvent repeatedly. No, other applications don't get time when a modal dialog is up. The way MultiFinder senses modality is by checking then window definition procedure. If a type dBoxProc is at the front, no other application will get time. -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "Our newest idol, the Superman, celebrating the death of godhead, may be younger than the hills; but he is as old as the shepherds." - Shaw, "On Diabolonian Ethics"
dlw@hpsmtc1.HP.COM (David L. Williams) (12/29/88)
>And Hmm...let's try that again: >"UNIX: the only operating system which has enough power and flexibility that ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Yeah, so where are all the great applications for us to use? UNIX is what 17+ years old has supposedly the most powerful development tools in the universe yet there doesn't seem to be a group of sexy, easy to use, fun applications. X and NeWS are still in there infancy and just as bad to program for as the mac is. UNIX as an OS still isn't the same on everyone's box witness OSF and the Unix International war. >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 ^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^ Yeah, but it seems to be about the only thing coming out of the "BEST" and "brightest" in the UNIX community. Sure more powerful hypertext systems have been developed at universities and thinktanks, but how many of them are available for me to purchase TODAY? I get a nice one for free from Apple, now. I get a great development environment from Symantec for about $100, that is fast and much each easier to use than ol cc and make are, let alone trying to figure out how to use a symbolic source level debugger. Where is this for UNIX? Sendmail and anon ftp still have backdoors in them? Yeesh, yuck ptooi! I'll take the ol Mac La Bomba over some dweeb grad student bringing the network to its knees. Whats lurking in uucp we don't know about? Don't get me wrong I like usenet/ARPA and notes..AHA I have found an application on UNIX I like! >nonetheless. perhaps "UNIX: the only operating system that hasn't realized its full potential" David L. Williams
lsr@Apple.COM (Larry Rosenstein) (12/29/88)
In article <6120@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >No, other applications don't get time when a modal dialog is up. The way >MultiFinder senses modality is by checking then window definition procedure. >If a type dBoxProc is at the front, no other application will get time. You are right that MultiFinder defines a modal dialog according to the window kind, and not as aresult of a call to ModalDialog. (Also, not that it doesn't matter if you are using a custom window defproc, if the kind is the same it is also considered modal.) Background application *DO* get time when a modal dialog is up, provided the foreground application yields the CPU. Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 46-B Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr
sec@berlin.acss.umn.edu (Stephen E. Collins) (12/29/88)
In article <6120@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes: > No, other applications don't get time when a modal dialog is up. The way > MultiFinder senses modality is by checking then window definition procedure. > If a type dBoxProc is at the front, no other application will get time. This statement is incorrect. Other applications DO get time when modal dialogs are up. I'm sure you can think of many methods to easily establish this fact; A quick easy way: 1. Bring up your favorite trivial application with a new file, and make some changes in the window (MacPaint?) 2. Bring up the "Find File" DA, and start it hunting for a file that doesn't exist. (You can HEAR and SEE it grinding away) 3. Click back to your favorite application, and click in the window's close box, which will bring up a modal dialog along the lines of "Save your changes?" 4. Look at this modal dialog, type dBoxProc, at the front, and WATCH and LISTEN to "find file" grinding away in the background. However, this still doesn't change my opinion that it would be much more robust to implement pre-emptive multitasking. +-----------------------------------------------------------------------+ | Stephen E. Collins | sec@ux.acss.umn.edu / | ACSS Microcomputer & Workstation Systems Group | sec@UMNACVX.BITNET / | 125 Shepherd Labs +-----------+-------------------/ | University of Minnesota | Cum hanc intellegas, Latinam / | Minneapolis, MN 55455 | sententiolam potes legere! / +------------------------------------+----------------------------+
han@Apple.COM (Byron Han, Architect) (01/03/89)
Having a modal dialogue does not mean that background tasks do not get time.
Whilst the modal dialogue is presented to the esteemed user, a certain
routine, ModalDialog, will be calling another routine, GetNextEvent, which
under MultiFinder, will cause time to be given to the background task.
Of course, if the user is holding down the mouse button for an extended
period of time, background tasks will be sad.
The modal dialogue (i.e. having a window with procID of dBoxProc) being front-
most in the front-most layer will prevent switching foreground tasks. The
reason that the statement is so specific is that I have mad MPW running
in background with a script which will bring up a modal dialog while MPW
is running as a background task. I can switch between other layers but when
I switch into the MPW layer I must dismiss the modal dialog before I can
switch out of MPW.
Hope this helps.
+-----------------------------------------------------------------------------+
| Disclaimer: Apple has no connection with my postings. |
+-----------------------------------------------------------------------------+
Byron Han, Communications Architect Almost alpha now.
Apple Computer, Inc. -------------------------------------
20525 Mariani Ave, MS27Y Internet: han@apple.COM
Cupertino, CA 95014 UUCP:{sun,voder,nsc,decwrl}!apple!han
-------------------------------------- GENIE: BYRONHAN
ATTnet: 408-974-6450 Applelink: HAN1 CompuServe: 72167,1664
------------------------------------------------------------------------------shebs@Apple.COM (Stanley Todd Shebs) (01/04/89)
In article <11540172@hpsmtc1.HP.COM> dlw@hpsmtc1.HP.COM (David L. Williams) writes: >Yeah, so where are all the great applications for us to use? UNIX is what 17+ >years old has supposedly the most powerful development tools in the universe >yet there doesn't seem to be a group of sexy, easy to use, fun applications. I used to wonder about that too, and started looking around. It seemed to me that an important use of Unix was to develop programs for other machines. For instance, there are hordes of programmers writing code for microprocessors in automobiles, microwaves, toasters, and so forth. Another group of users are institutions that have large applications like typesetting for books, airplane CAD databases, and investment analysis. "Sexiness" is less crucial than reliability, "fun" is less important than functionality. (This is not to say that Macs can't do typesetting, CAD, or trend analysis, but there is a big difference between modelling one valve and maintaining a database of *all* the parts in a 747!) It's interesting that from the end-user's point of view, Macs and PCs are the only computers used "as computers", that is, you can run different programs at different times for the purpose of processing information. Both embedded microprocessors and data-processing mainframes are by comparison part of the world's infrastructure, and rarely visible to non-programmers. stan shebs shebs@apple.com
dwb@Apple.COM (David W. Berry) (01/05/89)
In article <34550@think.UUCP> barmar@kulla.think.com (Barry Margolin) writes: >I have one question about this whole issue: Perhaps the whole situation can be explained by laying out two separate but connect entities. There are tasks and layers. A task is much like a UNIX process, they can even be run in the background. A layer on the other hand is a collection of windows belonging to a single task. Note that not all tasks own a layer, applications which have the "background only" bit of the SIZE resource don't get layers created and thus can't have windows. By extension then, there are task switches and there are layer switches. Task switches change the active task and layer switches change the active layer. Both task and layer switches happen during GetNextEvent. Layer switches are a direct result of user action, a mouse click somewhere. Task switches are a result of user inaction, no user events have occurred so let's see if anybody wants to do anything in the background. Task switches may occur while a modal dialog is displayed. Layer switches can't. Thus, background tasks, including inactive layers, do get execution time while a modal dialog is displayed, they just can't be made the current front layer. Opinions: MINE, ALL MINE! (greedy evil chuckle) David W. Berry apple!dwb@sun.com dwb@apple.com 973-5168@408.MaBell
asg@pyuxf.UUCP (alan geller) (01/11/89)
In article <23343@apple.Apple.COM>, dwb@Apple.COM (David W. Berry) writes: > > ... first, an excellent explanation of 'task switches' versus > 'layer switches', and how they're related to GetNextEvent. ... > > Task switches may occur while a modal dialog is displayed. > Layer switches can't. Thus, background tasks, including inactive > layers, do get execution time while a modal dialog is displayed, > they just can't be made the current front layer. > > David W. Berry > apple!dwb@sun.com dwb@apple.com 973-5168@408.MaBell Thanks for the explanation -- it was very clear. My question, though, is: WHY can't layer switches happen when a modal dialog is displayed? Or, alternatively, would it be possible to create a type of dialog that would be 'layer modal' rather than 'system modal'; that is, if such a dialog were displayed, then no other window/dialog/menu/control/etc. in the owning layer and task would be available to the user, but the user could switch layers (to a different task) if so desired? In other words, could modal dialogs just lock their owning task, rather than prohibit layer switches? It doesn't seem to me that this should be difficult; in some sense, it should be easier, as then the modal dialog manager doesn't have to be multi-finder aware (actually, I guess it isn't, it just hogs the mouse and keyboard; at least, I hope that's how it works). Of course, in some circumstances, you might want to prohibit layer switches (serious system errors, for example); in that case, why not have 'Layer Modal' and 'System Modal' dialogs? Or am I missing something? Likely I am; while I've used the Mac a good deal, I'm a novice at MacOS programming, so if I've missed something major and obvious, please, just explanations, no flames! Alan Geller Bellcore ...!{princeton|rutgers}!bcr!asg
matthews@eleazar.dartmouth.edu (Jim Matthews) (01/11/89)
In article <482@pyuxf.UUCP> asg@pyuxf.UUCP (alan geller) writes: >My question, though, is: > WHY can't layer switches happen when a modal dialog is displayed? > Or, alternatively, would it be possible to create a type of dialog > that would be 'layer modal' rather than 'system modal'; > that is, if such a dialog were displayed, then no other > window/dialog/menu/control/etc. in the owning layer and > task would be available to the user, but the user could > switch layers (to a different task) if so desired? I wondered about this myself when MF came out. I maintain a network terminal emulator that I wanted to do file transfer in the background, even though it won't let you get to another terminal session while file transfer is in progress. The trick is to fool MultiFinder about the "modality" of your dialog. MultiFinder considers a dialog to be modal if the window uses variation 1 (dBoxProc) of the window definition procedure. So if you use variation 2 (plainDbox), and point a userItem to a routine that draws the characteristic dBoxProc frame, you get a good approximation of a "normal" modal dialog. The frame takes an instant to draw, so it flickers some when the dialog is first updated. That's a pain, but it's worth it to be able to switch programs while a big file is coming down the wire. Here's my userItem procedure: procedure fakeDBox(wp : WindowPtr; itemNo : integer); var r : Rect; begin r := wp^.portRect; InsetRect(r,2,2); PenSize(2,2); FrameRect(r); PenSize(1,1); end; Jim Matthews Dartmouth Software Development
oster@dewey.soe.berkeley.edu (David Phillip Oster) (01/12/89)
In article <482@pyuxf.UUCP> asg@pyuxf.UUCP (alan geller) writes: > Or, alternatively, would it be possible to create a type of dialog > that would be 'layer modal' rather than 'system modal'; Sure, just use ResEdit to change the type of the window from "1" to "3" in its DLOG resource. It will come up with a slightly different window border, you'll be able to swap out under multi-finder, but the underlying application, calling ModalDialog() as it does, will be layer model. I've used this technique to modify terminal emulators to download in background. (you may also need to set the "can Background" bit in the size resource, so the terminal emulator will get some time, while it is not the top application. --- David Phillip Oster --"When we replace the mouse with a pen, Arpa: oster@dewey.soe.berkeley.edu --3 button mouse fans will need saxophone Uucp: {uwvax,decvax}!ucbvax!oster%dewey.soe.berkeley.edu --lessons." - Gasee
jackiw@cs.swarthmore.edu (Nick Jackiw) (01/12/89)
In article <482@pyuxf.UUCP> asg@pyuxf.UUCP (alan geller) writes: > > My question, though, is: > WHY can't layer switches happen when a modal dialog is displayed? > Or, alternatively, would it be possible to create a type of dialog > that would be 'layer modal' rather than 'system modal'; > that is, if such a dialog were displayed, then no other > window/dialog/menu/control/etc. in the owning layer and > task would be available to the user, but the user could > switch layers (to a different task) if so desired? > > Alan Geller > Bellcore > ...!{princeton|rutgers}!bcr!asg Mostly the answer to (A) concerns the event-driven programming model of Mac programs. Someone else has already pointed out that (B) is easy to do IF you're writing your own programs, but it's difficult to modify existing programs to give you what you want (layer-switching from beneath modals). Well-written Mac programs have a "main event loop" from which they can dispatch to various operating system or user requests to take some action, including (and this is a biggie for MultiFinder) redrawing their windows if necessary (because some other window's blocked them). At the beginning of the event loop, the program asks the system for an event. This is where MultiFinder might switch the layer out: the event-request never returns. Then, when MultiF needs to switch the layer back in, either to resume its topmost status or just to force it to redraw its corrupted windows, this pending event-request returns, and the program never needs to know it just spent some time in limbo. Enter the modal dialog difficulty. Modal dialogs are treated differently by apps than other windows, because there is a toolbox call (_ModalDialog) which will process all events pertaining TO THAT DIALOG ALONE. A mini-event loop, as it were. Now, imagine if MF were to snatch control out from the get-event-requests which are presumably buried in the call to _ModalDialog. There are no problems giving time to other tasks, and this is what MF does. If, however, it allowed another layer to come frontmost, that would corrupt the windows in the _ModalDialog layer. Now if User drags or resizes or closes a top-layer window, portions of the windows in the layer with the modal are going to be exposed, and consequently require updating in their back layer. Normally, MultiFinder would (TASK-)switch the app in, feed it its update events, and (TASK-)switch back to the frontmost layer. THE WHOLE PROBLEM: The modal app CAN'T PROCESS ITS UPDATES, or provide other key functionality, because it's not in its main event loop, it's only in the mini-event loop of the specific call to _ModalDialog. (Remember, this loop can't do anything but maintain the dialog.) So, if MF switched out from under a modal, that layer's windows would progressively deteriorate, until they were all just empty window frames (except for the modal window, which would get updated because _ModalDialog can process THOSE updates). Time for my disclaimer: this is all guesswork. I've never traced the code, and I have only a dim knowledge of the bowels of MultiFinder. I DO know that MF can't access your main-event-loop from within the ModalEventLoop, however: programs have to be explicitly coded to support that sort of re-entrancy, and most aren't. Programmers could easily design layer-switchable modals that resembled real ones, it would just require integrating modal-event handling with regular-event handling (and maintaining an internal flag indicating that USER- [vs. SYSTEM-] events which don't pertain to the pseudomodalwindow should be ignored. Sorry to be so longwinded. I knew there had to be a better reason than "it was a user-interface decision." This is my guess at one. No flames, thank you. -- +-------------------+-jackiw@cs.swarthmore.edu / !rutgers!bpa!swatsun!jackiw-+ | nicholas jackiw | jackiw%campus.swarthmore.edu@swarthmr.bitnet | +-------------------+-VGP/MathDept/Swarthmore College, Swarthmore, PA 19081--+ PER ASPERA AD ASTRA