Path: utzoo!attcan!uunet!cs.utexas.edu!uwm.edu!ux1.cso.uiuc.edu!csrd.uiuc.edu!usenet From: bruner@sp15.csrd.uiuc.edu (John Bruner) Newsgroups: comp.arch Subject: Re: Macintosh OS Message-ID: <1990Jun7.142800.4113@csrd.uiuc.edu> Date: 7 Jun 90 14:28:00 GMT References: <1990Jun6.055847.14995@d.cs.okstate.edu> <:SY35CD@xds13.ferranti.com> Sender: usenet@csrd.uiuc.edu (news) Reply-To: bruner@sp15.csrd.uiuc.edu (John Bruner) Organization: CSRD, University of Illinois Lines: 46 In-Reply-To: peter@ficc.ferranti.com (Peter da Silva) In article <:SY35CD@xds13.ferranti.com>, peter@ficc (Peter da Silva) writes: >How about the fact that programmers may have better things to do with their >time than warp code to fit into the windowing universe? I realise that on >the mac 90% of the programs are 90% user-interface, but that's not always >the best way to do things. A compiler, for example, really has no business >calling GetNextEvent *ever*. This is precisely one of my complaints about windowing systems in general. The implicit assumption seems to be that all programs should be restructured into big event loops. An application which doesn't call GetNextEvent() or XtAppProcessEvent() or whatever on a regular basis is "not well-behaved." Never mind that the application might have some complex long-running task to do. To operate "properly" it must artificially break up its computation into small pieces that can be executed in between calls to the event handler. Theoretically this can always be done, but is the added complexity during programming, debugging, and maintenance worth it? The Macintosh carries this idea further -- an application which isn't "well behaved" in this sense not only affects its own user-interface but also the execution of every other program in the system. An operating system is supposed to provide a set of facilities which support the development, debugging, and execution of programs. Cooperative multitasking doesn't do this -- the development of a program is *harder*, not easier in this environment. If the program goes into an infinite loop, what do you do? (On the Mac, you press the button which generates a non-maskable-interrupt, trap to the firmware debugger, hope that the interrupt didn't come at the wrong time, patch in an "exit-to-shell" system call, and try to continue with the rest of the applications. With a real operating system you type a special character or command and abort the offending task without affecting anything else.) By contrast, consider virtual memory. It is a very useful facility because each process can be written as though it had a large, private, physically-continugous address space, with system-supported walls between applications. Multiprogramming similarly should enable each process to run as if it had the entire machine to itself, but the "walls" in a cooperative multitasking system are thin indeed. How useful would virtual memory be if each process were required to service page faults and disc completion "events" for other processes running at the same time? -- John Bruner Center for Supercomputing R&D, University of Illinois bruner@csrd.uiuc.edu (217) 244-4476