luc14n0/glib
1
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/glib.git synced 2025-03-14 19:55:12 +01:00
Code Issues Packages Projects Releases Wiki Activity

added g_atomic_pointer_set() and g_atomic_int_set()

Browse Source 
Tue Dec 13 10:13:32 2005  Tim Janik  <timj@imendio.com>

	* glib/gatomic.h: added g_atomic_pointer_set() and g_atomic_int_set()
This commit is contained in:
Tim Janik 2005-12-15 02:23:15 +00:00 committed by Federico Mena Quintero
parent 7c24467a1c
commit 32ffaf4c32
2 changed files with 57 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
docs/reference/ChangeLog
View File

@ -1,3 +1,7 @@
2005-12-14 Federico Mena Quintero <federico@ximian.com>
* glib/building.sgml: Clarify exactly what happens when you use --enable-gc-friendly.
Mon Dec 12 15:31:41 2005 Tim Janik <timj@imendio.com> Mon Dec 12 15:31:41 2005 Tim Janik <timj@imendio.com>
* gobject/tmpl/objects.sgml: corrected floating reference documentation. * gobject/tmpl/objects.sgml: corrected floating reference documentation.

59
docs/reference/glib/building.sgml
View File

@ -218,15 +218,62 @@ How to compile GLib itself
<systemitem>--enable-gc-friendly</systemitem></title> <systemitem>--enable-gc-friendly</systemitem></title>
<para> <para>
When enabled all memory freed by the application, By default, and with <systemitem>--disable-gc-friendly</systemitem>
but retained by GLib for performance reasons as well, Glib does not clear the memory for certain objects before they
is set to zero, thus making deployed garbage are freed. For example, Glib may decide to recycle GList nodes by
collection or memory profiling tools detect putting them in a free list. However, memory profiling and debugging tools like <ulink
unlinked memory correctly. This will make GLib url="http://www.valgrind.org">Valgrind</ulink> work better if an
slightly slower and is thus disabled by default. application does not keep dangling pointers to freed memory (even
though these pointers are no longer dereferenced), or invalid pointers inside
uninitialized memory. The
<systemitem>--enable-gc-friendly</systemitem> option makes Glib clear
memory in these situations:
</para> </para>
</formalpara> </formalpara>
<itemizedlist>
<listitem>
<para>
When shrinking a GArray, Glib will clear the memory no longer
available in the array: shrink an array from 10 bytes to 7, and
the last 3 bytes will be cleared. This includes removals of single and multiple elements.
</para>
</listitem>
<listitem>
<para>
</para>
</listitem>
<listitem>
<para>
When growing a GArray, Glib will clear the new chunk of memory.
Grow an array from 7 bytes to 10 bytes, and the last 3 bytes will be cleared.
</para>
</listitem>
<listitem>
<para>
The above applies to GPtrArray as well.
</para>
</listitem>
<listitem>
<para>
When freeing a node from a GHashTable, Glib will first clear
the node, which used to have pointers to the key and the value
stored at that node.
</para>
</listitem>
<listitem>
<para>
When destroying or removing a GTree node, Glib will clear the node,
which used to have pointers to the node's value, and the left and right subnodes.
</para>
</listitem>
</itemizedlist>
<para>
Since clearing the memory has a cost,
<systemitem>--disable-gc-friendly</systemitem> is the default.
</para>
<formalpara> <formalpara>
<title><systemitem>--disable-mem-pools</systemitem> and <title><systemitem>--disable-mem-pools</systemitem> and
<systemitem>--enable-mem-pools</systemitem></title> <systemitem>--enable-mem-pools</systemitem></title>