Stewart Smith wrote: > On Mon, 2008-07-14 at 10:48 -0400, Jay Pipes wrote: >> Stewart Smith wrote: >>> On Mon, 2008-07-14 at 00:20 -0700, Brian Aker wrote: >>>> To you does it make sense to have a mashup of glibc and talloc? It >>>> sounds like a mess. >>> Perhaps we could blend talloc and some of our existing stuff and end up >>> with a decent string library..... or, perhaps it is possible to make >>> glib do talloc, i'd need to look a bit closer. >> I answered this in an earlier thread (no pun intended). Yes, it is >> absolutely possible. It is done using the g_mem_set_vtable() function: >> >> http://library.gnome.org/devel/glib/2.16/glib-Memory-Allocation.html#g-mem-set-vtable > > This doesn't seem to work too well with a hierarchical memory allocator > like talloc though. > > The main beauty of talloc is that allocations are linked together in a > tree. > > So when you say "allocate memory for a connection" every bit of memory > you allocate that's related to that connection, you allocate under the > context of that connection. It's then possible to easily go "here is all > the memory used by this connection". > > It also means that talloc_free(connection) goes and frees all the memory > for that connection. It makes it *really* hard to get it wrong. > > While with glib you still can - you have to manually free everything. > Which is fraught with difficulties. It's also hard to track allocation. > > If we had all allocation done through talloc we could very easily have > an I_S table that listed where all the memory was going for each > connection in the server.... which could be rather powerful/useful.
Hi again! Yes, indeed, it sounds like it would be a very nice profiling tool. To be sure, glib provides a number of not-so-automatic-but-still-cool methods of providing destructors for various things. For instance g_hash_table_new_full() allows you to register destructor callbacks for items stored in the has (both the keys and the values) which get called upon g_hash_table_destroy(). Using g_mem_profile() and a GMemVTable struct, you can get some pretty cool mem profiling too. Like we discussed yesterday, we need to determine if either of these things proves to be a significant improvement or regression for memory alocation performance over our existing MEM_ROOT stuff -- I don't think we need to wonder about my_malloc()... ;) -jay _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
