GTK+ Forums

just a quick question: does GTK3 provide memory pool functionality? in future?

Hi,

GTK+ is a graphical tool kit and does not deal with low level stuff like memory allocation. For memory functions you need to look at the Glib library which GTK+ depends on.

Is there a particular need for memory pools which the Glib g_slice_*() functions can not do for you?

_________________
E.

The g_slice_*() still burdens the user to free the memory. A memory pool enables a session-oriented programming. At the beginning of a session you create a memory pool. Then, you create objects in the memory pool during the session. Note that you don't need to care about their lifetimes. Finally, at the end of the session all you have to do is to destroy the memory pool.

http://dev.ariel-networks.com/apr/apr-t ... ial-3.html

g_slice_* generally will use the slab allocator common on unix/BSD systems. It represents a way of creating equally sized chunks of prealigned memory that can be used to avoid fragmentation. In this way it is a memory pool.

Memory pools with a single end of session freeing of memory have their hazards and have to be specifically designed for the particular application. There is often a vicious circle of programming languages, etc. trying to reduce buggy code by being designed to hide/remove burdens of developers, who in turn take the internals for granted; unaware of the constraints they operate under and end up producing sloppy buggy code.

Yes, the GTK developer is still expected to clean up memory. g_slice_ does do it one at a time but you can do it in a single function call with g_slice_free_chain. Beyond g_slice_* GTK is built on a reference tracking system that allows data reuse between multiple widgets, etc. where lifetime is quite important for determining when memory can be freed.

If you're really concerned about burdening the developer with freeing memory then GTK is available with a number of language bindings (e.g. python) in which you'd likely find several where everythign memory related is done behind the scenes. The other option is, with the memory pool idea, why do it in dynamic memory in the first place (Just declare yourself an array in static memory)? Wouldn't you throw away all of the advantages by having a fixed size pool (and if that's not the case wouldn't chunks have to be freed individually)?

One might request a memory larger than a preallocated equal-sized chunk. In this case, a good memory pool implementaion shall find several continuous chunks.
On the other hand, one might request more memory that currently preallocated. In this case, a good memory pool implementaion shall enlarge itself.
From a user's point of view, he/she only needs to call apr_palloc(size) to get memory as needed, and at end destroy the memory pool.
If we use g_slice_alloc(), would it cause too many memory requests and releases? Does g_slice_free_chain() require the user to carefully organize all requested memories of different sizes into a chain? I might misunderstand its purpose.

The Apache Portable Runtime which as given as a reference does state that it has its own problems.



and



Also looking at the API it does seam overly complex in that you have now burdened the developer with keeping track of the various pointers to the memory pools.

With the g_slice_alloc() and g_slice_new() functions if the memory to be allocated is small it would be placed in a memory pool that has the same size. When freeing the memory you must know what the size of the memory block is.

Another option is to use the Glib data types if this fits in with how you are using your allocated sections of memory. There are many different data types including arrays and linked lists and all offer an option of freeing all allocated memory in one go if you wish. This way you will integrate better with the rest of the Glib/GDK/GTK libraries.

_________________
E.