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

Reply via email to