Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!ames!xanth!kent From: kent@xanth.cs.odu.edu (Kent Paul Dolan) Newsgroups: comp.sys.amiga.tech Subject: Re: Disk corrupt - task held Keywords: guru to the maximum frustrastion Message-ID: <5597@xanth.cs.odu.edu> Date: 15 Jun 88 21:12:11 GMT References: <1657@vaxb.calgary.UUCP> <3932@cbmvax.UUCP> <2108@sugar.UUCP> <5564@xanth.cs.odu.edu> <2120@sugar.UUCP> Reply-To: kent@cs.odu.edu (Kent Paul Dolan) Distribution: na Organization: Old Dominion University, Norfolk Va. Lines: 146 In article <2120@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: [???] >In article ... kent@xanth.cs.odu.edu (Kent Paul Dolan) writes: >> In article <2108@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >> >As an aside: I've been re-reading Bach's book and thinking about >> >running UNIX tasks under AmigaDOS.... > >> >The MMU overhead would be about zip with just one task (since you >> >wouldn't ever be switching UNIX contexts). > >> Huh? I frequently spawn 16 or 20 tasks to run in background >> under BSD 4.3, (not during business hours and survive, but at >> 3 AM...) ... > >If you're on an Amiga you're running at least 16 or 20 tasks: Intuition, >console windows, all your open devices, all your programs, etc... Remember >the diagram at the front of all the RKMs. > You sort of ignored the point here, Peter. We weren't talking about AmigaDOS tasks, we were talking about Unix. You said Unix wouldn't be wasting time swapping tasks, and I demurred. Picture a demon unix power user who bought her new Amiga because it was the most cost effective Unix box on the block. She has code to design and deadlines to meet, so she's going to learn AmigaDOS as time allows, but she is going to expect to come in and run Unix right out of the box, and get her work done. She bought the system, after all, to port her knowledge easily to new hardware; otherwise she'd be looking harder at OS/MTdiv2 (if the multitasking version ever hits the streets), or MacMultiFinder. Don't tell her she can only run one Unix task at a time, or that is the last Amiga sale in her circle of acquaintance. >> switching among with the extremely easy ^Z, % job >> control of 4.3 BSD. > >I'll take Intuition any day. If you don't like mice, just load up wKeys >and hit your own window select routine. So will I, but I know how to use it; that isn't the buyer AmiIX is aimed at; why bother preaching to the converted? >> I suppose I'm missing something here, but >> if I'm coming to this machine as a power Unix user, I expect >> this stuff to work on AmiIX too, > >It will, just as well as on your 68020 UNIX... that is considerably less >well than an equal number of AmigaDOS processes. Sure, since AmigaDOS does tasks and processes. Still not the point; your statement was: The MMU overhead would be about zip with just one task (since you wouldn't ever be switching UNIX contexts). I hope that is not what gets designed; it won't sell a second Amiga. >> and I'll pick up on that >> strange AmigaDOS thingie as time allows. What have I missed? > >What you've missed is that AmigaDOS has way less overhead than UNIX, so >on a given peice of iron you're going to get way better response time under >AmigaDOS. The overhead I'm talking about is the UNIX task-switching. You >don't need UNIX task overhead for getty, init, and all the other trusted >programs. And what I described wasn't the system facilities that always run in background, but little fiascos like spawning twenty shars or ten sendmails of eleven letters each all at once (both of which I've done within the last month; the sendmails were an accident, how was I to know a script with ten commands in a row was going to drop them all into the background for asynchronous processing? The script had no internal "&"'s, so I expected them to run one by one. The system came to a pretty good imitation of flash frozen for about three minutes until all those letters were waiting in spool files, and of course this was the middle of the afternoon.) Lots and lots of times I will background a couple of zoo's while I check on the success of another, or edit a cover letter; that is just normal Unix use. There's _lots_ of Unix task switching going on, among application level tasks, even if I'm the only user online. >> >To AmigaDOS the UNIX task would look like another Amy task, but with >> >traps to gracefully kill it if it gets out of bounds. > >> This "bounds" is going to be a nice entity; scatter load the >> Unix process, > >Why scatter-load the UNIX process? Change contexts, look at an AmigaDOS power user who wants to use Unix just every once in a while. I might be several hours into my work day when I decide to bring up Unix, and I don't have checkpointing built into my stray cycle eating ray tracer, so I expect to come up in the existing memory fragmentation, not have to reboot. Why would you design any process running under AmigaDOS, least of all something as big as AmiIX, to not scatter load? All the docs say the opposite. >> and have a few Amiga processes acquiring and >> releasing memory, as Unix jobs malloc and free, and find an >> easy way to describe the boundary. ;-) > >UNIX jobs never shrink, you know. I suppose we could do UNIX one better here >and use AllocMem and FreeMem, but there's really no point in improving on >that. You can allocate memory to the UNIX process however you like. If it >gets too fragmented it, you can always shuffle it around. You can even have >it demand paged. If you really want to go nutso, you can assign a big chunk >of memory to UNIX (like, all but 512K or so) and use UNIX memory management >inside it. There are lots of solutions to these problems. Does "Unix jobs never shrink" mean "free" is a scam? This really doesn't affect the argument, though, because even if all Unix does is add memory, with AmigaDOS adding and freeing memory, the Unix portion will share some of the complexity of spagetti. Of course, if you have a huge superabundance of memory, you can always just give the Unix process the top half, but we have seen at least one reverse of the memory cost curve trend, so maybe we should plan on less than superabundant memory; and design for the "must use efficiently and well" case instead. >> Kent, the man from xanth. > >Kent, do you have to be so negative all the time? How about engaging in some >constructive criticism. Suggest alternative methods for doing things. Try to >keep important facts (like the relative performance of UNIX and the Amiga >EXEC) in mind. Just what purpose are you trying to serve here? Well, I've seen a lot of projects start off with this "piece of cake" attitude, and get killed off when they started eating up much more time and money than projected. Poking Unix in as a process under AmigaDOS has a lot of attractive features, and might well turn out to be a good idea, but requirements specs are supposed to be conservatively scoped out so management gets as few nasty shocks as possible. You don't get that kind of analysis if everybody plays Pollyanna. I happen to be of a conservative nature, so it is my natural part to question unproved feasibility; whether in the end my worries prove true or false, they serve a useful purpose in the early going. Sorry if you don't like having to defend your ideas. I guess I should just let you rattle on uninterrupted. Kent, the man from xanth.