🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.amiga.tech
Article #9084

Re: Disk corrupt - task held

#9084
From: Kent Paul Dolan
Date: Wed, 15 Jun 1988 21:12
146 lines
7695 bytes
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-number> 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.
Technical Details
Message-ID: <5597@xanth.cs.odu.edu>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!water!watmath!clyde!att!pacbell!ames!xanth!kent
References: <1657@vaxb.calgary.UUCP> <3932@cbmvax.UUCP> <2108@sugar.UUCP> <5564@xanth.cs.odu.edu> <2120@sugar.UUCP>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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