In which sense is pushing GAllocators MT-safe?

[Utz-Uwe Haus <haus saturn Math Uni-Magdeburg DE>]

Hi,

I'm using glib in a project not related to gnome, as a nice, portable
C utility library. In a way it performs great. On the other hand I'm facing
a problem regarding glib's handling of memory. 

My problem is as follows [currently using 1.2.6 and .7]:
In using GHashTable and GSList the library manages some memory chunks to
boost performance. In the first case that is done using the node_mem_chunk
in ghash.c, in the second case useing a GAllocator object. My code uses,
at some point, an enormous amount of memory in the form of GSList, say 1G.
Soon after that it no longer needs the lists, and destroys them. Glib
does not (using the default GAllocator object) release that memory,
so the rest of my code can never access it - a bad thing. 
Using my own GAllocator object via g_slist_push_allocator() fixes that, as
I can pop the allocator when done and get the memory back, if not into
the OS pool, then at least into the malloc pool. This is not MT safe though,
since I can not safely destroy the GAllocator object, since a concurrent thread
might have allocated some list using it, and freeing the allocator
destroys all it's chunks, right? Pushing a seperate allocator in each
thread preceding each list operation is not an option either, since that is 
a) timeconsuming and generally ugly, and b) needs another global mutex to 
avoid some thread popping another ones allocator (anybody still with me?).

For GHashTables the problem is similar, but I don't even see a way to
free the mem_chunks, say when I know after 5% of the runtime that I will
never again need a hashtable in the remaining 4 weeks of runtime...

Any expert out there to help me pry into the innards of glib here? What I
would like to do is something like
	* write a "free all kept memory" function in ghash.c [not too hard]
	* keep the GAllocator stack with the individual List object
	  (which is probably not liked by those who consider GSList a kind
	   of cons-cell :>), maybe this has to be a new object type
	* .. or be told how to do it with the current library

Thanks in advance,

Utz

-- 
Utz-Uwe Haus                               haus@mail.math.uni-magdeburg.de
Inst. f. Math. Optim.                                        utz@uuhaus.de
Uni Magdeburg                    PGP keys  1024/6AD23BE1 and 2048/5D0B72A1
GERMANY                          available via keyservers or email request