added g_atomic_pointer_set() and g_atomic_int_set()
authorTim Janik <timj@imendio.com>
Thu, 15 Dec 2005 02:23:15 +0000 (02:23 +0000)
committerFederico Mena Quintero <federico@src.gnome.org>
Thu, 15 Dec 2005 02:23:15 +0000 (02:23 +0000)
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()

docs/reference/ChangeLog
docs/reference/glib/building.sgml

index 1318d7bb3fdd2c637551d28ce96c820343063139..2a4ed64df553c75792c593a24786c5ba2ec550ca 100644 (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>
 
        * gobject/tmpl/objects.sgml: corrected floating reference documentation.
index 93c9abfc70d8abc72e7a7f858efc4dd2c05bcaa3..02d063d5cbb8498af17acff233be6a4878f8c6ce 100644 (file)
@@ -218,15 +218,62 @@ How to compile GLib itself
           <systemitem>--enable-gc-friendly</systemitem></title>
 
         <para>
-          When enabled all memory freed by the application,
-          but retained by GLib for performance reasons
-          is set to zero, thus making deployed garbage
-          collection or memory profiling tools detect
-          unlinked memory correctly. This will make GLib
-          slightly slower and is thus disabled by default.
+         By default, and with <systemitem>--disable-gc-friendly</systemitem>
+         as well, Glib does not clear the memory for certain objects before they
+         are freed.  For example, Glib may decide to recycle GList nodes by
+         putting them in a free list.  However, memory profiling and debugging tools like <ulink
+         url="http://www.valgrind.org">Valgrind</ulink> work better if an
+         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>
       </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>
         <title><systemitem>--disable-mem-pools</systemitem> and
           <systemitem>--enable-mem-pools</systemitem></title>