MARK CALLAGHAN wrote:
On Thu, Feb 26, 2009 at 11:17 PM, Monty Taylor <mord...@sun.com> wrote:
Therefore, I'm going to say that what we _really_ want instead of
mem_root is what Jay and I have been pushing for for a while - resource
management through ownership. Pointers to allocated memory should be
contained in, owned by and managed by an object, such that when the
object goes away, so does the memory. It's almost like magic how much a
nice containment hierarchy can achieve the end-goal of mem_root.
I'd post a code sample... but I'm falling asleep sitting here... I'll
come back to this in the morning. :)
Monty
I am curious about how this will deal with the problem of memory
allocations that have different lifetimes. The popular ones in
non-drizzled MySQL are:
* global -- get it from malloc() today
* per connection -- get it from the THDs mem_root today
* per session -- not sure if it exists today
* custom -- not sure if it exists today
Having more than one lifetime is already a problem as you need to be
very careful when maintaining a pointer to an object that has a
shorter lifetime (objects from the global allocation can't point to
per-session, ...).
An object destructor typically deletes objects that it "owns". In cases
where more than one object may have pointers to another, reference
counting is generally used. When an object is shared among threads,
reference counting with interlocked instructions is necessary. Objects
that can have circular dependencies require something more sophisticated.
Many C-based database systems use memory pools for objects of the same
lifetime. Firebird, for example, allocates a pool for a statement to be
compiled. At end of compilation, the pool is released and everything
goes away like magic.
The two models don't mix at all, which is why there are more database
systems written in C+ (credit to Brian this time) than C++.
Having used each model extensively, the C++ destructor mechanism is
clearly superior, but requires some getting used to. But destructors
must be called, and the C++ allocation mechanism doesn't provide memory
allocators with enough information to call them.
Trying to mimic memory pools in C++ is possible, but is more work and
overhead than making a personal accommodation to C++.
--
Jim Starkey
President, NimbusDB, Inc.
978 526-1376
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : drizzle-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp