GTK+ Forums

Discussion forum for GTK+ and Programming. Ask questions, troubleshoot problems, view and post example code, or express your opinions.
It is currently Fri Nov 28, 2014 6:55 am

All times are UTC




Post new topic Reply to topic  [ 6 posts ] 
Author Message
 Post subject: GTK3 memory pool functionality?
PostPosted: Tue Dec 18, 2012 3:08 pm 
Offline
Familiar Face

Joined: Sun Dec 16, 2012 9:09 pm
Posts: 12
just a quick question: does GTK3 provide memory pool functionality? in future?


Top
 Profile  
 
 Post subject: Re: GTK3 memory pool functionality?
PostPosted: Tue Dec 18, 2012 9:20 pm 
Offline
Never Seen the Sunlight

Joined: Mon Apr 28, 2008 5:52 am
Posts: 781
Location: UK
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.


Top
 Profile  
 
 Post subject: Re: GTK3 memory pool functionality?
PostPosted: Wed Dec 19, 2012 4:04 pm 
Offline
Familiar Face

Joined: Sun Dec 16, 2012 9:09 pm
Posts: 12
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


Top
 Profile  
 
 Post subject: Re: GTK3 memory pool functionality?
PostPosted: Wed Dec 19, 2012 11:55 pm 
Offline
Never Seen the Sunlight

Joined: Thu Mar 24, 2011 2:10 pm
Posts: 328
Location: Sydney, Australia
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)?


Top
 Profile  
 
 Post subject: Re: GTK3 memory pool functionality?
PostPosted: Thu Dec 20, 2012 5:15 am 
Offline
Familiar Face

Joined: Sun Dec 16, 2012 9:09 pm
Posts: 12
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.


Top
 Profile  
 
 Post subject: Re: GTK3 memory pool functionality?
PostPosted: Thu Dec 20, 2012 7:50 am 
Offline
Never Seen the Sunlight

Joined: Mon Apr 28, 2008 5:52 am
Posts: 781
Location: UK
The Apache Portable Runtime which as given as a reference does state that it has its own problems.

Quote:
REMARK: There is no limitation about memory chunk size that you can allocate by apr_palloc(). Nevertheless, it isn't a good idea to allocate large size memory chunk in memory pool. That is because memory pool is essentially designed for smaller chunks. Actually, the initial size of memory pool is 8 kilo bytes. If you need a large size memory chunk, e.g. over several mega bytes, you shouldn't use memory pool.


and

Quote:
REMARK: By default, memory pool manager never returns allocated memory back to the system. If a program runs for a long time, it would have problem.


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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC


Who is online

Users browsing this forum: Google [Bot] and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group