UH2@psuvm.psu.edu (Lee Sailer) (03/27/90)
Though I had never used it myself, I'd always wondered why more people don't use this memory allocator. It works something like this: struct Remember *list ... AllocRemember (list, numberofbytes, typeofmemoryflags); .... more AllocRemember() calls that allocate more memory The idea is that info about the exact location and size of each piece of allocated memory is stored in the list (including memory automagically allocated to manage the list. Then, when it comes time to free up all the memory, just FreeRemember(list); So, I finally tried to do this myself, but alas couldn't get it to work. Thanks to the wonders of modern C, the compiler led me to the problem. In Mortimer's oftentimes useful Amiga book, he says that the first argument to AllocRemember should be a pointer to a Remember structure, as I've shown above. In the include file prototypes, however, the first argument is a pointer to a pointer to a Remember structure. I don't know what the RKM say. Since there are lots of us cheapskates who still haven't acquired the RKM, there are lots of us who've been mislead by this little error in Mortimer. The correct call seems to be AllocRemember(&list, size, flags); I say seems to be because I tried it and everything seems to be working OK. Still, I could be wrong. So, I think one reason few people use AllocRemember() is that there is some misleading documentation about it, so people get frustrated by it. Other reasons are that ARP offers a similar service, plus it isn't that hard to create your own, similar capability once you see the need for it. lee
aduncan@rhea.trl.oz.au (Allan Duncan) (03/28/90)
From article <90086.093011UH2@psuvm.psu.edu>, by UH2@psuvm.psu.edu (Lee Sailer): > Though I had never used it myself, I'd always wondered why more people > don't use this memory allocator. It works something like this: > . . . > So, I think one reason few people use AllocRemember() is that there is > some misleading documentation about it, so people get frustrated by > it. Other reasons are that ARP offers a similar service, plus it > isn't that hard to create your own, similar capability once you see > the need for it. > > lee I have also devised a method for generalizing this chaining to cover all resources. If you are doing the job properly and checking for (say) a library, and it is unavailable and you need to abort the program, you end up with more code for freeing what you had got up to that point than it took to get there! Solution - create a list (with backward linking) that has a pointer to the resource, some parameter (say, size), and a pointer to a function that will release it (eg free() for a malloc'd chunk). When it comes time to back out, just call a routine that runs back down the list, checking for a non-null resource pointer (you might have already let it go) and invoking the freeing function. Takes a bit to set up the first time, but is easy to re-use. Allan Duncan ACSnet a.duncan@trl.oz ARPA a.duncan%trl.oz.au@uunet.uu.net UUCP {uunet,hplabs,ukc}!munnari!trl.oz.au!a.duncan Telecom Research Labs, PO Box 249, Clayton, Victoria, 3168, Australia.
bleys@tronsbox.UUCP (Bill Cavanaugh) (03/29/90)
>Item: 6283 by [Lee Sailer] > Subj: AllocRemember() The Lattice compiler_headers definition in proto/intuition.h is char *AllocRemember(struct Remember **, long, long); The RKM says: "The Remember structure is defined in intuition/intuition.h as follows: struct Remember { struct Remember *NextRemember; ULONG RememberSize; UBYTE *Memory; }; The contents of the Remember structure are handled by the system, but are explained here for completeness." The example does indeed use AllocRemember(&rememberKey, SIZE_A, FLAGS_A). /************************************************************ * * * Everything above is copyright me. All rights unreserved. * * uunet!tronsbox!bleys * * * * "The perversity of the universe tends to a maximum" * * Finagle's First Law * * J. Pournelle * * * ************************************************************/