Re: [Glib Internals] Request for help: a brief explaination of gmem's design
- From: Owen Taylor <otaylor redhat com>
- To: Ryan McDougall <ryan mcdougall telusplanet net>
- Cc: gtk-devel-list gnome org
- Subject: Re: [Glib Internals] Request for help: a brief explaination of gmem's design
- Date: Mon, 05 Jan 2004 13:56:56 -0500
On Sat, 2004-01-03 at 17:24, Ryan McDougall wrote:
> Hello,
> I am steadily making my way through the source code, but I cant seem to
> get my head around what gmem is doing and why -- basically I can't
> visualize what its doing and why, which makes reading the code harder
> than it needs to be. I can guess some, but I'd really like to *know*.
> Part of the problem is that I don't think that the documentation uses
> consistent terminology, ex: constantly uses area, blocks, chunks,
> segments, etc. apparently interchangeably and without defining them.
I don't see 'blocks' used at all. The one use of 'segment' I see
looks like it means 'atom'
> Can anyone tell me if I've got this straight, and let me know what I'm
> missing?
>
> Atoms are "indivisible", contiguous bytes designed to hold whole data
> types such as chars, ints, structs, etc.
>
> Areas are like arrays of atoms, that is contiguous multiples of Atoms.
>
> Chunks are pools (if so I think GMemPool is a better name) of
> dis-contiguous sets of (possibly different sized) Areas held in a
> loop-up tree, designed to act as a memory management object that knows
> about which of its sub-areas are in use or can be freed.
- All areas are the same size
- The tree's only purpose is to map from atom to the area holding
the atom. Which atoms are in use is tracked by the free_atoms
list in the GMemChunk and the various fields of GMemArea.
Regards,
Owen
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]