Xref: utzoo comp.sys.amiga:22369 comp.sys.amiga.tech:1677
Path: utzoo!utgpu!water!watmath!clyde!att!chinet!mcdchg!ditka!stb!michael
From: michael@stb.UUCP (Michael)
Newsgroups: comp.sys.amiga,comp.sys.amiga.tech
Subject: Re: resource reclamation
Summary: Semi-detailed Strawman proposal for 2.0 resource tracking
Message-ID: <10575@stb.UUCP>
Date: 31 Aug 88 18:29:38 GMT
References: <3763@louie.udel.EDU>
Reply-To: michael@stb.UUCP (Michael)
Followup-To: comp.sys.amiga.tech
Organization: STB BBS, La, Ca, Usa, +1 213 459 7231
Lines: 77

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.