Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!ADS.ARPA!neville From: neville@ADS.ARPA.UUCP Newsgroups: mod.computers.68k Subject: Re: R. Heller's note on Multitasking, etc. Message-ID: <8702140223.AA03867@ucbvax.Berkeley.EDU> Date: Fri, 13-Feb-87 21:20:04 EST Article-I.D.: ucbvax.8702140223.AA03867 Posted: Fri Feb 13 21:20:04 1987 Date-Received: Sat, 14-Feb-87 14:19:53 EST Sender: mwm@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 58 Approved: info-68k@ucbvax.berkeley.edu i have to agree with Robert on implementation points, but i really disagree on the utility of Multi-tasking in any form without real memory protection. (By the way, Robert, Unix was designed as a single-user system and abstracted out to what it is today.) He and i have had this argument several times before; might as well move it into a public forum. Robert talks about the Stride "Multi-user" BIOS that allows more than one task at a given terminal (all tasks must be same OS) and more than one active terminal at a time (each terminal may be running a different OS). i, too, have one of these machines and i, too, am running CP/M-68K. Now, it should be noted that none of the (what are, in my opinion) faults of this setup are because of that selection of OS. Instead, they are caused by the underlying *real* OS, the Multi-user BIOS. Many times i have been running simultaneous foreground/background processes and had memory trashed in one process because of a stray pointer (from that 1 last bug) in the other process. i have gotten to the point that i just don't do code development with more than one process running. i have experienced just about every possible bad side-effect of this that one could imagine. It is aggravated by the fact that the MU-bios runs separate kernels for each process (how else can you run Pick, MoSys, P-system, and CP/M-68K all at the same time?) and that there is no way to safely write in directories from 2 processes. Robert's stated solution is the only one that makes sense -- don't write-share directories. Now, with OS/9 or Minix or even Micro RTX (ever heard of the Beckemeyer MT C-Shell?) , you of course don't have the directory problem but you still have the risk of one process interfering with another and in practice i find this unacceptable. Maybe Amiga users get used to booting their machine when one program goes wild, but that is not my idea of a usable operating system. For this reason, i have been in "grin and bear it" mode for a while, just waiting for Stride to realize they should sell me their 68010 + MMU "daughter board" for the 68000 socket without making me buy their Unix and for Project GNU to actually get enough work done on the Trix kernel that i can hook my BIOS drivers into it and do some parallel development. i have also had pointers to the German mag "c't", who are supposedly doing a 68020 + MMU daughter board, but i haven't checked it out. i can't see using OS/9 or Minix, because of the reasons and experiences mentioned above. The only way to be to get the level of protection that i would want is to do as someone else suggested and keep only one process resident at a time, swapping them to disk at each context switch. Granted, i have a fast hard disk, but either i would be spending all my time swapping for large processes or wasting most of my 4Mb memory on small processes. -neville ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ U.S. Mail: Neville D. Newman Advanced Decision Systems 201 San Antonio Circle, Suite 286 Mountain View, CA 94040-1289 Phone: (415) 941-3912 Net mail: neville@ads.arpa (internet-relative)