nw@palladium.UUCP (08/29/87)
In article <1708@amiga.amiga.UUCP>, bart@amiga.UUCP (Barry A. Whitebook) writes: > this is amiga!bart: just a little background on why there is no "kill" > > in order to safely kill a process on the amiga, it would be necessary to > either 1) keep track of all memory which it has allocated since launch > 2) make sure that none of this memory is currently "owned" by another process > 3) either free this memory OR live with the fact that it is forever lost to > the system... (until reboot) > > this is not to mention the fact that the system would have to keep track of > all the other resources in use by that process (flush asynchronous io, close > libraries, etc) > > unless and until all processes respond to "kill" signals by performing > hari-kiri themselves the SYSTEM OVERHEAD for these is both too high ^^^^^^^^^^^^^^^ ^^^^^^^^ This I must strongly disagree with, for a number of reasons. First of all, every program ever written for the Amiga contains code that keeps track of the resources it allocated (ok, not *every* program, but every program you'd ever want to run!). There are many types of overhead implicit here: 1) Programmer time (think of how much $$$ Commodore has spent paying people for "goto out1; ... goto out2; ... etc). Think of how much more every software developer has spent writing (and debugging) such code. 2) Run-time memory space to hold all the "unwind" code. Note that this gets multiplied by the number of applications in memory. 3) CPU-cycles for the application to store the information it needs to run the "unwind" code (e.g., maintaining "Remember" lists, checking things in the "out1:" code, etc). From a total-system perspective, it seems much less clear to me that leaving resource tracking out of the OS is justified on the basis of overhead. Looking specifically at memory allocation: There are heap-allocator algorithms that perform much better than the simple "ordered list of free memory blocks" algorithm it looks like Exec is using. Knuth describes one (sorry, book is not where I am right now); all these algorithms require that you have structures associated with *both* allocated and free memory. The resource tracking of memory will come almost for free once you have these structures. Result: big performance GAIN from smarter algorithms, small loss for resource tracking code, net GAIN. Remember: you're using more memory in Exec, but you have saved code and "Remember" structures (or the functional equivalent) in N applications. For other structures it probably won't work out quite as nicely. Resource tracking will indeed increase the code and data space requirements of the various Amiga OS components. It will also slow them down by adding a few extra instructions to the allocation functions. But again, the question is not one of raw size/performance numbers for the Amiga OS, but for the total system. I believe that you would use much less memory with resource tracking in the OS. I believe that the total CPU cycles expended would be a wash -- the same either way. > and too full of race conditions (some processes may have spwaned subtasks). I'm not certain what this really means. The OS already needs to know how to prevent races in various algorithms. On "loaning" memory: Yes, this complicates things. Note that it is already a problem today. If I put code into an application so it can commit hari-kiri (sp?), I still had better be sure not to free any memory I loaned out. It's not any easier (nor any harder) for the OS to do the same. What's needed here are some shared-memory primitives, ala System V or the new Berkeley proposals. Not, obviously, the whole nine yards but a subset that allows two or more processes to declare that they're all using the same piece of memory. At my former job (hi Mike!) I designed implemented major portions of a proprietary operating system that wasn't really much different from Exec/AmigaDOS (well, no BCPL! and it was multi-cpu). Resource tracking was essential, and the time spent implementing it was certainly paid back by the time saved writing applications. I designed the entire I/O system, which permitted processes to have multiple asynchronous I/O requests (like Exec) and still kept track of who was doing what to whom. I also designed and implemented the entire shared memory system ... again, with resource tracking. Oh yes, we also didn't have an MMU. So, memory fragmentation is definitely a problem. But not having an MMU doesn't make resource tracking any harder (it makes it easier ... no page tables and swap space to track). Oh well. Not having resource tracking is rather obviously firmly engraved into the Amiga culture by now. Too bad. -- Neil Webber / Palladium Data Systems / (No longer confused with Jordan Marsh) Marlboro MA, 01752 {linus!alliant, harvard!cfisun}!palladium!nw
harald@ccicpg.UUCP ( Harald Milne) (09/18/87)
I for one wish to keep this issue simple. Very simple. An issue has
been raised to contend with resource management. Handle your devices, handle
your memory, but the hell with messages!
Imagine if you will, you are using UNIX on NFS. A machine is down.
You try like hell to talk, but the sucker is dead! Timeout or deal with in
another way. And if you can't, HANG on a MSGPORT. Big Deal! If your system
is screwed up so much, it deserves drastic action. It's a bug. Reboot if you
have too. Or KILL the OTHER offending TASK! And who cares if memory is
allocated to BOGUS messages! If there isn't enough, well reboot. The point is,
you are a sorry state of affairs. You might as well go GURU. BUT you don't have
to go so soon.
There is no rule that says you can't KILL the opposing task that
waits for the NEVER arriving message!.
My final point is: I don't wan't to see UNIX on the amiga. UNIX is
a HUGE PIG! Please don't make me make nasty CONTEXT SWITCHES! Thrash the
Amiga OS all you will.
Elegance PLEASE! We have the example of why UNIX is screwed up!
Do we wan't it on the Amiga?
--
Work: Computer Consoles Inc. (CCI), Advanced Development Group (ADG)
Irvine, CA (RISCy business! Home of the CCI POWER 6/32)
UUCP: uunet!ccicpg!harald