Path: utzoo!utgpu!attcan!uunet!super!udel!rochester!cornell!batcomputer!riley
From: riley@batcomputer.tn.cornell.edu (Daniel S. Riley)
Newsgroups: comp.sys.amiga.tech
Subject: Re: resource reclamation
Message-ID: <6180@batcomputer.tn.cornell.edu>
Date: 1 Sep 88 15:11:53 GMT
References: <3763@louie.udel.EDU> <10575@stb.UUCP>
Reply-To: riley@tcgould.tn.cornell.edu (Daniel S. Riley)
Organization: Cornell Theory Center, Cornell University, Ithaca NY
Lines: 24

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.