bart@amiga.UUCP (Barry A. Whitebook) (08/26/87)
[ eat this line - please! ] this is amiga!bart: just a little background on why there is no "kill" (and why memory gets fragmented...) 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 < a loan effective occurs when a message is sent from one process to another - that is, between the time that a message is received at a port and the time that it is replymsg'd() the receiving process relys on its existing and being unmodified, effectively it becomes "owned" by the receiving task > 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-kirithemselves the SYSTEM OVERHEAD for these is both too high and too full of race conditions (some processes may have spwaned subtasks). a variant of the above is why coalescing of memory fragments on the amiga can be blocked under some conditions: taska allocates some, taskb allocates some, taska allocates some more and until taskb frees its "middle" chunk the contiguous region represented by aba can't be coalesed even if taska frees all. (also note that the system PERFORMS memory un-fragging whenever POSSIBLE!) this posting is not to discourage the thought of a "better" solution: but as long as we have no MMU... bart.
elg@killer.UUCP (08/28/87)
in article <1708@amiga.amiga.UUCP>, bart@amiga.UUCP (Barry A. Whitebook) says: > this is amiga!bart: just a little background on why there is no "kill" > (and why memory gets fragmented...) [bunches of reasons] > this posting is not to discourage the thought of a "better" solution: > but as long as we have no MMU... > > bart. I'm in the midst of a multitasking kernal right now, somewhat similiar in concept to the Amiga's except a bit simpler, and I, too, at first saw no easy way to keep track of all resources. First, there's message ports. Well, these are part of the kernel, so the kernel can send a "process killed" message through open ports, and the i/o manager et. al. could handle gracefully closing files and so forth. So that handles tracking i/o. Then, there's memory management. It is possible to tag each block of memory here with a process number, just like above, and tell the malloc that process xyz died and add its memory to the freelist. However, this would also require linking together all the used blocks of memory into a "usedlist". So we're talking about 3 bytes of overhead for each block of memory. So how large is the average block of memory in an Amiga? I dunno. Then there's the bytes used for messages. You'd have to say that they were part of the memory of the sending process, because generally "C" malloc library routines request a large amount of memory and subdivide it. So the first task upon killing the process will have to be emptying out any pipes that have messages pending from this process, because they are null and void... Since my project is for a dedicated environment, on a machine that I won't disclose for fear of being laughed out of this newsgroup, I'll never have to face any of those questions. But, whereas I started out skeptical that resource tracking was possible, I am now much more optimistic... I/O: DOS keeps track of what process associated with what file, for orderly shutdown. "kill" routine sends some sort of KILL packet with associated procid, telling it who to zap. Message ports: Message port handler keeps track of these. Things can get hairy here with "KILL" packets and "deadly embrace" and such, but all in all, things can be made managable. Memory: Tag blocks with process IDs. Have "usedlist" as well as freelist so that killr can find the tagged blocks when killing RAM. problems: overhead. Depends on how big of blocks applications request. So there's the three major resources of the Amiga, tracked on a per-process basis. So it SHOULD be possible, WITHOUT a MMU. It just all depends on how braindamaged the DOS REALLY is, as to whether it's possible ON THE AMIGA.... -- Eric Green elg@usl.CSNET Do-it-yourselfer's maxim: {cbosgd,ihnp4}!killer!elg Don't force it, use a bigger hammer! Snail Mail P.O. Box 92191 Lafayette, LA 70509
peter@sugar.UUCP (Peter da Silva) (08/28/87)
Isn't there a "end task" entry in the task structure? Is that entry called in a way compatible with 'C'? If not, how much glue would you need? Can't you implement a "kill" program that calls this routine? The other thing you need to do then is add a "set kill action" routine to the 'C' library that sticks the address of a specified routine into that slot (this routine, of course, has to end with a terminate task call...)? That's much better than having to watch for SIGB_CTRLC all through your code. Existing tasks (which presumably just "kill myself") would leave junk all over the place... but at least they'd be gone. This would also take care of nerds who forget to make sure they call their cleanup routines before exiting. -- -- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter -- U <--- not a copyrighted cartoon :->
jvkelley@watcgl.waterloo.edu (Jeff Kelley) (08/30/87)
If you missed the summary, look again. That's one way of killing a task,
the well known drawback being that resources owned by the task, other
than memory placed on its tc_MemEntry structure, will not be released.
(Does the AmigaDOS 'RUN' command place the process structure, its stack,
and the loaded segments on this list? Probably not, but it's pretty
simple to do (I wrote a program called 'RunTask' which does this.))
Neat trick: If you like a mouse cursor that behaves like an air-hockey
puck, follow these steps:
1) Find or write a program which opens a window and calls
WindowToFront() every second. Clock programs are likely
choices.
2) Run several copies simultaneously. Three worked for me.
Wait for the system to lock-up. (Shouldn't take more
than a minute.)
3) After the system returns from its mysteriously locked state
(lasting for 2-30 seconds), the mouse cursor should behave
like an air hockey puck. Quickly close the windows,
before the next mysterious lock-up.
4) Lock-ups will no longer occur, but your mouse cursor will
continue to behave in this interesting fashion. Enjoy.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
UUCP: {ihnp4,watmath}!watcgl!jvkelley | Postal Address:
BITNET: jvkelley@cgl.waterloo.bitnet | Jeff Kelley
INTERNET: jvkelley@cgl.waterloo.edu | Dept. of Computer Science
EAN: jvkelley@cgl.waterloo.cdn | University of Waterloo
| Waterloo, Ont., Canada
| N2L 3G1
| tel: (519) 578-4514sat@unicus.UUCP (S.A. Thurlow) (08/31/87)
In article <581@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >Isn't there a "end task" entry in the task structure? Is that entry >called in a way compatible with 'C'? If not, how much glue would you >need? Can't you implement a "kill" program that calls this routine? True, but this is not as good as it seems. You see, if I don't set things up right in my task structure, your kill won't free the memory and close the devices I've allocated. It is the application programmer's responsibility to set up and maintain the "end task" entry in the task structure. (I wish I could give more information here, but my RKM is at home). >The other thing you need to do then is add a "set kill action" routine >to the 'C' library that sticks the address of a specified routine into >that slot (this routine, of course, has to end with a terminate task >call...)? Yeah, BUT AllocMem's, open windows, open devices, etc. are still not tracked. You would need to redo the resource management routines so ALL memory and device allocations are tracked and can be undone by the "end task." The OS really should do this to guarantee that kill will always have the same affect. As it is now, a kill will behave differently for different applications. It is the application programmer's (or his compiler's) responsibility to make sure things are set up right for the kill to work. How many application programmers are there out there? How many C compilers? How many adventurous programmers who are going to muck with task structure behind the OS's back? Good luck in getting everyone to cooperate. >That's much better than having to watch for SIGB_CTRLC all through your >code. Existing tasks (which presumably just "kill myself") would leave >junk all over the place... but at least they'd be gone. True. What does intuition do with windows/screens that don't belong to any task? >This would also take care of nerds who forget to make sure they call >their cleanup routines before exiting. The resource allocations can be tracked by writing wrappers functions for the allocation routines, and hoping that everyone uses these wrappers. Any ideas on how to enforce this? I guess a really smart compiler could substitute rom calls with a call to the appropriate wrapper function. >-- >-- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter >-- U <--- not a copyrighted cartoon :-> -- Scott A. Thurlow Unicus Corporation InterNet: sat@Chi.Unicus.COM (on a good day) UUCP: {uunet!mnetor,utzoo!utcsri}!unicus!sat (on a bad day) ARPA: uunet!mnetor!unicus!sat@Seismo.CSS.GOV (on a REALLY bad day) BITNET: THURLOW@UTORGPU (you figure this out)
glee@cognos.uucp (Godfrey Lee) (09/04/87)
In article <935@unicus.UUCP> sat@unicus.UUCP (S.A. Thurlow) writes: >Yeah, BUT AllocMem's, open windows, open devices, etc. are still not >tracked. You would need to redo the resource management routines so ALL >memory and device allocations are tracked and can be undone by the "end >task." The OS really should do this to guarantee that kill will always >have the same affect. That last statement is so true that I don't know why we are wasting time discussing ways to track/free resources by the programmer. Every other O/S I have dealt with (including MSDOS!) tracks resources. This missing functionality in Amiga/DOS stands out like a sore thumb when compared with the rich functionalities like message passing, device/event driven etc... Something like this might not sound like that big a deal, because the system works without it, but it has far reaching effects in that programmers cannot rely on the system to trap and protect the system from runaway programs, causing guru (aka system crash really), making debugging harder, giving worse reputation to commercial software, that due to the inevitable bug, trashes the Amiga where on another system, might just abort the program. Bottom line is that it makes the programmer's job harder, and makes the machine look like a flake! So lets end the discussion, and simply ask Commodore to raise the priority of adding resource tracking to the top of the things-to-do list. I would even ask them to consider that it is really a bug. I would like to take an e-mail vote: "Do you want Commodore to add resource tracking into the next release of the operating system, even to the exclusion of something else?" Please answer only YES or NO, and please answer only via e-mail. I will tabulate only those votes and post the result on the net. -- Godfrey Lee P.O. Box 9707 Cognos Incorporated 3755 Riverside Dr. VOICE: (613) 738-1440 FAX: (613) 738-0002 Ottawa, Ontario UUCP: decvax!utzoo!dciem!nrcaer!cognos!glee CANADA K1G 3Z4
rick@oresoft.UUCP (Rick Lahrson) (09/08/87)
In article <935@unicus.UUCP> sat@unicus.UUCP (S.A. Thurlow) writes: > It is the application programmer's (or his >compiler's) responsibility to make sure things are set up right for the >kill to work. ... >The resource allocations can be tracked by writing wrappers functions >for the allocation routines, and hoping that everyone uses these >wrappers. Any ideas on how to enforce this? I guess a really smart >compiler could substitute rom calls with a call to the appropriate >wrapper function. Please! It's not any compiler's responsibility, nor is it appropriate for a compiler, to do things the programmer didn't ask for. A compiler's job is translating one language into another, maintaining semantic equivalence. If you want a "wrapper routine" called, call it. The compiler will translate the call to that routine just as happily as a call to the rom (which is really a call to a wrapper routine anyway). Resource tracking is properly the operating system's job. I wish the Amiga hadn't been so rushed to get to market that the planned operating system couldn't be finished. I'd love to see an operating system for the Amiga that would live up to the quality that makes the Amiga such a miracle. But that's a huge changeover -- not that there couldn't be new routine calls that handled resource tracking fairly transparently, but a huge change due to all the existing structures that contain those stupid, disgusting BPTR's. (Now there's a job that a compiler SHOULD be able to do -- generate code that relates to the target machine!) I wonder how willing most developers would be to switch over to a new operating system (in other words, convert all their programs) if the new operating system was of such impeccable quality, integrity, and elegance that it was loved for its beauty, like the rest of the Amiga. I know I would. -- Rick Lahrson ...tektronix!oresoft!rick Disclaimer: If I ever speak for anyone but me, I'll warn you in advance.
peter@sugar.UUCP (Peter da Silva) (09/10/87)
Your heart's in the right place, but your reasoning isn't valid. > Every other O/S I have dealt with (including MSDOS!) tracks resources. While I think the lack of resource tracking in the Amiga is little short of criminal (Rhetorical comment, but only semi :->), MS-DOS doesn't do any better. Just try exiting a program without closing all your files first some time. In fact the only PC operating system that does a better job than AmigaDOS is the Mac finder. Of course it has a much simpler job: what with all a tasks memory being in a fixed-size partition. > [programmers can't] rely on the system to trap and protect the system from > runaway programs,... Resource tracking wouldn't help here. You would need hardware memory protection. No other personal computer does any better here, except maybe the Atari ST which has bounds registers... unfortunately, the O/S does not make effective use of this feature of the hardware. I had as much or more trouble with crashing on the ST as on the Amiga. > So lets end the discussion, and simply ask Commodore to raise the priority > of adding resource tracking to the top of the things-to-do list. I would even > ask them to consider that it is really a bug. Yes. -- -- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter -- 'U` <-- Public domain wolf.