🚀 go-pugleaf

In article <8908082312.AA10140@jade.berkeley.edu> (Valentin Pepelea) writes:
>How about a new flag for the memory allocation routines? If resource tracking
>is to be implemented, MEMF_NOTRACK would guarantee a memory block which would
>not be tracked, and therefore not be deallocated when the program exits.

Isn't this the tail wagging the dog? Why can't we just build a *real* set
of memory allocation routines on top of the Exec routines like the original
developers intended? Have the equivalent of malloc and free or some other
set of routines that track the memory for you. Currently, C users can just
use these two to allocate and deallocate memory, and when the program exits
they all get freed. Things like device nodes which are cons'd up and given
away should have constructor/destructor functions that are separate from 
the memory allocation routines. About the only OS support I can think of
would be to put the memory on some "well known" list (like tc_MemEntry) 
so that all of the compiler writers would know where to stick their
memory allocations to be freed. Of course we need some way of selecting
"types" of memory which the C library routines don't provide. But this
is more of an interface problem than anything else. AllocMem() has all 
of the constructs it needs to be a good underlying allocator, now lets
build a nice set of user friendly routines on top of it.


--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.
"A most excellent barbarian ... Genghis Kahn!"