> The easiest way to get this behaviour would be to write a local
> allocator which offered those semantics. I did this at one point
> with a head implementation that allowed watermarking. Basically you
> could make watermarks at various times, and then free all
> still-valid allocations back to the named watermark (yeah, single
> threaded with linear process flows).
For the truly brave, along those lines:
http://www.gnu.org/manual/glibc-2.2.3/html_chapter/libc_3.html#SEC34
Change the hooks, and you won't even need to change the code that you need
to put in a separate memory "boxcar"...Design functions that flag a given
memory pointer as contained in a given boxcar, set the hooks appropriately
when you want to watch for this, and then, when the questionable code is
done, just detach that whole boxcar from the metaphorical memory train and
put the original hooks back.
This could also be a poor man's garbage collector, if you've got leaky
code, and, if coded right, won't add too much overhead to the existing
program.
That being said, someone needs to speak reasonably and say that all of
this is interesting, but bad, bad practice. Shrugging your shoulders and
saying "hey, it's a video game after all, so who cares if it's got leaks
in the first place and I choose a non portable hack to fix them in the
second?" is not only shortsighted, but it says a lot about game coding
mentalities that are rampant in the industry.
I would recommend that you attack memory problems with the correct tools:
dmalloc, ElectricFence, mcheck(), etc. It may save your sanity later on.
--ryan.
|
