bader+@andrew.cmu.edu (Miles Bader) (08/17/88)
How come simple resource reclamation isn't done? It seems like it would be pretty simple to hang a list of allocated resources off a task... -Miles
cmcmanis%pepper@Sun.COM (Chuck McManis) (08/18/88)
[Mr. Hoogerbeats, add this one to your list ...] In article <YX2ERcy00Uh0IEQFxo@andrew.cmu.edu> (Miles Bader) writes: > How come simple resource reclamation isn't done? It seems like it > would be pretty simple to hang a list of allocated resources off a > task... > -Miles Because it isn't. The original DOS specified for the Amiga included resource reclamation, however when time got tight and Commodore had to go with MetaCompCo's modified version of TriPOS, there wasn't time to put it in. If you look at some of the structures you will notice that there entries for Tasks such as tc_MemEntry which were for this kind of stuff. That is not to say that it isn't possible. The ARP project (AmigaDOS Replacement Project) has created a library which allows you to track resources and free them on exit. The ARP stuff in on a Fish disk #??? and available thru the amiga archives. The question Miles didn't ask but always follows is : How come I can't kill a hung process with ^C or something? And when the program breaks why do I have to reboot the machine? The reason is that the Amiga does not have memory protection between tasks. And when a program goes astray, you do not know what sort of damage it may have caused to internal memory structures. It can damage the memory free list, trackdisk buffers, the stack of other programs, and a host of other "sensitive" areas. Consequently, if you continue to run the machine after a program has died, you run the much greater risk of destroying completely unrelated data. For most people this is unacceptable and that is why you have to reboot. For those people who like to gamble, there is a commercial program called GOMF which attempts to recover from these situations. It does keep the machine running, however if another program you are running crashes, you should be aware that it is much more likely that the originally crashed program probably is responsible, not a bug in the code that just ran. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
michael@stb.UUCP (Michael) (09/01/88)
In article <3763@louie.udel.EDU> iphwk%MTSUNIX1.BITNET@cunyvm.cuny.edu (Bill Kinnersley) writes: > ... >But on the Amiga there are many more resources to worry about. An aborted >process may have opened MessagePorts, IORequests, Windows, Screens, etc. >Each of these requires a different specific cleanup action, not just >freeing of memory. The actions may even have to be taken in a definite >order. > >Conceivably you could keep track of all these things and write a general >cleanup routine. Then someone will add his own library and expect the >system to cleanup those resources too. Perfect. I couldn't have put it better myself. Consider this: O/S 1 prints a file by having a print program. It knows all about various types of files, and can handle just about everything out there. Then someone adds a new type of file with their handy-dandy wiz-bang program. REsult: Printing fails. O/S 2 prints a file by having a default tool for each file, with a command to print sent to it. A new handy-dandy program is added, and the print routines are supplied with it. REsult: Printing works. Now, O/S 2 is object-oriented. (It also is the Mac, but thats not important). Replace printing with resource allocation/de-allocation. Now: Method one: A special library is written to track all resource usage. Then a new resource is defined. It fails. Method two: All libraries are written to track their own resource allocations and releases. Now things work. Method zero (none of the above) is the Amiga. Method 1 is ARP. This is a suggestion for 2.0: Define a resource. All tasks/processes/whatever have a list of lists. (Allows the CLI to have one set of resources and its "children" other sets). Each sublist contains a list of the resources this thing owns. All things that work with resources have the following operations defined: RS_ALLOC: Resource being allocated RS_FREE: Resource is to be free'd. RS_TRANS: Resource is being transfered from one owner to another RS_SPLIT: Resource is being duplicated others as needed. Implementation of a resource would be a structure with two elements: a function pointer, and a void * (initialized to NULL) (8 bytes, AllocMem's favorite size). The function would take 2 args, one is the command, the other is the resource for which this is done. ALLOC would take the structure, malloc() some memory, and set the void * to it. FREE would clean up, and free() that memory. For cli task killing, just call FREE on each resource in the sublist. For complete process killing, do this on every sublist in the list. Examples: Opening a file. User calls Open(). Open gets the current sublist for this process, adds a resource structure, calls the filesystem-handler for the appropriate device, (File-system handler would add a structure for the file lock, handle an internal ALLOC), does an internal ALLOC for the File Handle, then returns it to the user. Hmm... brings up two points. One, the ALLOC would generally be internal to the library and not generally available (but not always. ALLOC would be well defined for creating I/O requests (no more hard coding for all the different possible i/o request size and device specific initializations)), and two, another pointer for sub-resources is needed (consider that when a user wants to dup() that file handle, the lock will need to be duplicated also. Ditto for tansfered. So thats 12 bytes total, a node overhead (this is an exec list, after all) (next, prev, etc.), about 32 bytes for the complete structure. Ok, so we don't use it for memory allocation tracking :-) Followups to c.s.a.tech : --- : Michael Gersten uunet.uu.net!denwa!stb!michael : sdcsvax!crash!gryphon!denwa!stb!michael : Coff Coff <=== Stop smoking.
riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (09/01/88)
In article <10575@stb.UUCP> michael@stb.UUCP (Michael) writes: [...stuff about resource tracking was here...] > >Method one: A special library is written to track all resource usage. Then >a new resource is defined. It fails. >Method two: All libraries are written to track their own resource allocations >and releases. Now things work. > >Method zero (none of the above) is the Amiga. Method 1 is ARP. I think you're underrating ARP a little. Look at the section on TRAK_GENERIC in the ARP programmer's manual. Basically, when you allocate a resource, you put TRAK_GENERIC in the tr_ID field, and a pointer to your code to deallocate the resource in tg_Function. When FreeTrackedItem sees a TRAK_GENERIC, it does a few integrity checks, and then calls your cleanup function, which does something and returns a code teling FreeTrackedItem whether or not the tracker node should be deallocated. They got a little carried away with unions, so you have to extend the TrackedResource structure with some private data to make it general (*sigh*), but it's more than just method one. -dan riley (dsr@lns61.tn.cornell.edu, dsr@crnlns.bitnet) -wilson lab, cornell u.
cc1@valhalla.cs.ucla.edu (Michael Gersten) (09/09/88)
In article <6180@batcomputer.tn.cornell.edu> riley@tcgould.tn.cornell.edu (Daniel S. Riley) writes:
:In article <10575@stb.UUCP> michael@stb.UUCP (Michael) (Me, different address)
:[...stuff about resource tracking was here...]
:>
:> [Comparing one library that knows about everyone's resources vs. each library
:> knowing about its resources]
:
: [Daniel's reply: ARP does have a facility for generic tracked resource
: cleanup.]
Not bad; I was not aware of this. Now, what about duplcation and ownership
transfering? (The amiga right now allows almost any resource to be transfered
to another process; any replacement scheme must allow for this as well)