On Fri, 2008-07-11 at 17:12 -0700, Brian Aker wrote: > Hi! > > Lets figure out a memory policy first. I talked to Jay about this for > a bit today. What I would like to do is sit down at OSCON and write up > a plan for how to tackle memory. > > We have (at a least): > > 1) Short lived, per query. > 2) Medium lived, per login session > 3) Forever > > We also have the issue that some things, like Tables, are not per > session and are cached. > > I would like to define these out, and create a strategy that is > written down and someone and go to when they ask "how do I allocate > memory?" > And everything should be error checked/type checked.
I'll cheer for talloc again. talloc macros/functions are typesafe (no typecasting). freeing a talloc context frees everything hanging off that context (unless you've increased a reference count elsewhere). you can attach destructors. it's all C. you can get reports out of talloc on where memory is allocated - essentially doing leak checking but a lot cheaper than with valgrind. it's maintained by really smart people (that are others, doesn't have to be us). -- Stewart Smith ([EMAIL PROTECTED]) http://www.flamingspork.com/
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
