KGRKJGETMRETU895U-589TY5MIGM5JGB5SDFESFREWTGR54TY
Server : Apache/2.2.17 (Unix) mod_ssl/2.2.17 OpenSSL/0.9.8e-fips-rhel5 DAV/2 PHP/5.2.17
System : Linux localhost 2.6.18-419.el5 #1 SMP Fri Feb 24 22:47:42 UTC 2017 x86_64
User : nobody ( 99)
PHP Version : 5.2.17
Disable Function : NONE
Directory :  /usr/share/gtk-doc/html/gobject/

Upload File :
current_dir [ Writeable ] document_root [ Writeable ]

 

Current File : //usr/share/gtk-doc/html/gobject/gobject-memory.html
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=US-ASCII">
<title>Object memory management</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
<link rel="start" href="index.html" title="GObject Reference Manual">
<link rel="up" href="chapter-gobject.html" title="The GObject base class">
<link rel="prev" href="chapter-gobject.html" title="The GObject base class">
<link rel="next" href="gobject-properties.html" title="Object properties">
<meta name="generator" content="GTK-Doc V1.6 (XML mode)">
<link rel="stylesheet" href="style.css" type="text/css">
<link rel="preface" href="pr01.html" title="Introduction">
<link rel="part" href="pt01.html" title="Part&#160;I.&#160;Concepts">
<link rel="chapter" href="ch01.html" title="Background">
<link rel="chapter" href="ch02.html" title="The Glib Dynamic Type System">
<link rel="chapter" href="chapter-gobject.html" title="The GObject base class">
<link rel="chapter" href="chapter-signal.html" title="The GObject messaging system">
<link rel="reference" href="rn01.html" title="API Reference">
<link rel="reference" href="rn02.html" title="Tools Reference">
<link rel="part" href="pt02.html" title="Part&#160;IV.&#160;Tutorial">
<link rel="chapter" href="howto-gobject.html" title="How To define and implement a new GObject?">
<link rel="chapter" href="howto-interface.html" title="How To define and implement Interfaces?">
<link rel="chapter" href="howto-signals.html" title="Howto create and use signals">
<link rel="part" href="pt03.html" title="Part&#160;V.&#160;Related Tools">
<link rel="chapter" href="tools-gob.html" title="GObject builder">
<link rel="chapter" href="tools-ginspector.html" title="Graphical inspection of Gobjects">
<link rel="chapter" href="tools-refdb.html" title="Debugging reference count problems">
<link rel="chapter" href="tools-gtkdoc.html" title="Writing API docs">
<link rel="index" href="ix01.html" title="Index">
<link rel="index" href="ix02.html" title="Index of deprecated symbols">
<link rel="index" href="ix03.html" title="Index of new symbols in 2.2">
<link rel="index" href="ix04.html" title="Index of new symbols in 2.4">
<link rel="index" href="ix05.html" title="Index of new symbols in 2.6">
<link rel="index" href="ix06.html" title="Index of new symbols in 2.8">
<link rel="index" href="ix07.html" title="Index of new symbols in 2.10">
<link rel="index" href="ix08.html" title="Index of new symbols in 2.12">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<table class="navigation" id="top" width="100%" summary="Navigation header" cellpadding="2" cellspacing="2"><tr valign="middle">
<td><a accesskey="p" href="chapter-gobject.html"><img src="left.png" width="24" height="24" border="0" alt="Prev"></a></td>
<td><a accesskey="u" href="chapter-gobject.html"><img src="up.png" width="24" height="24" border="0" alt="Up"></a></td>
<td><a accesskey="h" href="index.html"><img src="home.png" width="24" height="24" border="0" alt="Home"></a></td>
<th width="100%" align="center">GObject Reference Manual</th>
<td><a accesskey="n" href="gobject-properties.html"><img src="right.png" width="24" height="24" border="0" alt="Next"></a></td>
</tr></table>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="gobject-memory"></a>Object memory management</h2></div></div></div>
<p>
	The memory-management API for GObjects is a bit complicated but the idea behind it
	is pretty simple: the goal is to provide a flexible model based on reference counting
	which can be integrated in applications which use or require different memory management
	models (such as garbage collection, aso...). The methods which are used to
	manipulate this reference count are described below.
</p>
<pre class="programlisting">
/*
  Refcounting
*/
gpointer    g_object_ref                      (gpointer        object);
void        g_object_unref                    (gpointer        object);

/*
  Weak References
*/
typedef void (*GWeakNotify)		(gpointer      data,
					 GObject      *where_the_object_was);
void	    g_object_weak_ref		      (GObject	      *object,
					       GWeakNotify     notify,
					       gpointer	       data);
void	    g_object_weak_unref		      (GObject	      *object,
					       GWeakNotify     notify,
					       gpointer	       data);
void        g_object_add_weak_pointer         (GObject        *object, 
                                               gpointer       *weak_pointer_location);
void        g_object_remove_weak_pointer      (GObject        *object, 
                                               gpointer       *weak_pointer_location);
/*
  Cycle handling
*/
void        g_object_run_dispose	      (GObject	      *object);
</pre>
<p>
      </p>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
<a name="gobject-memory-refcount"></a>Reference count</h3></div></div></div>
<p>
	  The functions <code class="function"><a href="gobject-The-Base-Object-Type.html#g-object-ref">g_object_ref</a></code>/<code class="function"><a href="gobject-The-Base-Object-Type.html#g-object-unref">g_object_unref</a></code> respectively 
	  increase and decrease the reference count.These functions are thread-safe as of GLib 2.8.
	  The reference count is, unsurprisingly, initialized to one by 
	  <code class="function"><a href="gobject-The-Base-Object-Type.html#g-object-new">g_object_new</a></code> which means that the caller
          is currenly the sole owner of the newly-created reference.
          When the reference count reaches zero, that is, 
	  when <code class="function"><a href="gobject-The-Base-Object-Type.html#g-object-unref">g_object_unref</a></code> is called by the last client holding
	  a reference to the object, the <span class="emphasis"><em>dispose</em></span> and the 
	  <span class="emphasis"><em>finalize</em></span> class methods are invoked.
	</p>
<p>
	  Finally, after <span class="emphasis"><em>finalize</em></span> is invoked, 
	  <code class="function"><a href="gobject-Type-Information.html#g-type-free-instance">g_type_free_instance</a></code> is called to free the object instance.
	  Depending on the memory allocation policy decided when the type was registered (through
	  one of the <code class="function">g_type_register_*</code> functions), the object's instance 
	  memory will be freed or returned to the object pool for this type.
	  Once the object has been freed, if it was the last instance of the type, the type's class
	  will be destroyed as described in <a href="gtype-instantiable-classed.html" title="Instantiable classed types: objects">the section called &#8220;Instantiable classed types: objects&#8221;</a> and 
	    <a href="gtype-non-instantiable-classed.html" title="Non-instantiable classed types: Interfaces.">the section called &#8220;Non-instantiable classed types: Interfaces.&#8221;</a>.
	</p>
<p>
	  The table below summarizes the destruction process of a GObject:
	  </p>
<div class="table">
<a name="gobject-destruction-table"></a><p class="title"><b>Table&#160;2.&#160;<code class="function"><a href="gobject-The-Base-Object-Type.html#g-object-unref">g_object_unref</a></code></b></p>
<table summary="g_object_unref" border="1">
<colgroup>
<col align="left">
<col align="left">
<col align="left">
</colgroup>
<thead><tr>
<th align="left">Invocation time</th>
<th align="left">Function Invoked</th>
<th align="left">Function's parameters</th>
<th>Remark</th>
</tr></thead>
<tbody>
<tr>
<td align="left">Last call to <code class="function"><a href="gobject-The-Base-Object-Type.html#g-object-unref">g_object_unref</a></code> for an instance
		    of target type</td>
<td align="left">target type's dispose class function</td>
<td align="left">GObject instance</td>
<td>
		    When dispose ends, the object should not hold any reference to any other
		    member object. The object is also expected to be able to answer client
		    method invocations (with possibly an error code but no memory violation)
		    until finalize is executed. dispose can be executed more than once.
		  dispose should chain up to its parent implementation just before returning
		  to the caller.
		  </td>
</tr>
<tr>
<td align="left">Last call to <code class="function"><a href="gobject-The-Base-Object-Type.html#g-object-unref">g_object_unref</a></code> for an instance
		    of target type
		  </td>
<td align="left">target type's finalize class function</td>
<td align="left">GObject instance</td>
<td>
		    Finalize is expected to complete the destruction process initiated by
		    dispose. It should complete the object's destruction. finalize will be
		    executed only once.
		  finalize should chain up to its parent implementation just before returning
		  to the caller.
		    The reason why the destruction process is split is two different phases is
		    explained in <a href="gobject-memory.html#gobject-memory-cycles" title="Reference counts and cycles">the section called &#8220;Reference counts and cycles&#8221;</a>.
		  </td>
</tr>
<tr>
<td align="left">Last call to <code class="function"><a href="gobject-The-Base-Object-Type.html#g-object-unref">g_object_unref</a></code> for the last
		    instance of target type</td>
<td align="left">interface' interface_finalize function</td>
<td align="left">On interface' vtable</td>
<td>Never used in practice. Unlikely you will need it.</td>
</tr>
<tr>
<td align="left">Last call to <code class="function"><a href="gobject-The-Base-Object-Type.html#g-object-unref">g_object_unref</a></code>for the last
		    instance of target type</td>
<td align="left">interface' base_finalize function</td>
<td align="left">On interface' vtable</td>
<td>Never used in practice. Unlikely you will need it.</td>
</tr>
<tr>
<td align="left">Last call to <code class="function"><a href="gobject-The-Base-Object-Type.html#g-object-unref">g_object_unref</a></code> for the last
		    instance of target type</td>
<td align="left">target type's class_finalize function</td>
<td align="left">On target type's class structure</td>
<td>Never used in practice. Unlikely you will need it.</td>
</tr>
<tr>
<td align="left">Last call to <code class="function"><a href="gobject-The-Base-Object-Type.html#g-object-unref">g_object_unref</a></code> for the last
		    instance of target type</td>
<td align="left">type's base_finalize function</td>
<td align="left">On the inheritance tree of classes from fundamental type to target type. 
		    base_init is invoked once for each class structure.</td>
<td>Never used in practice. Unlikely you will need it.</td>
</tr>
</tbody>
</table>
</div>
<p>		
	</p>
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
<a name="gobject-memory-weakref"></a>Weak References</h3></div></div></div>
<p>
	Weak References are used to monitor object finalization: 
	<code class="function"><a href="gobject-The-Base-Object-Type.html#g-object-weak-ref">g_object_weak_ref</a></code> adds a monitoring callback which does
	not hold a reference to the object but which is invoked when the object runs 
	its dispose method. As such, each weak ref can be invoked more than once upon
	object finalization (since dispose can run more than once during object 
	finalization).
	</p>
<p>
	<code class="function"><a href="gobject-The-Base-Object-Type.html#g-object-weak-unref">g_object_weak_unref</a></code> can be used to remove a monitoring
	callback from the object. 
      </p>
<p>
	Weak References are also used to implement <code class="function"><a href="gobject-The-Base-Object-Type.html#g-object-add-weak-pointer">g_object_add_weak_pointer</a></code>
	and <code class="function"><a href="gobject-The-Base-Object-Type.html#g-object-remove-weak-pointer">g_object_remove_weak_pointer</a></code>. These functions add a weak reference
	to the object they are applied to which makes sure to nullify the pointer given by the user
	when object is finalized.
      </p>
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
<a name="gobject-memory-cycles"></a>Reference counts and cycles</h3></div></div></div>
<p>
	Note: the following section was inspired by James Henstridge. I guess this means that 
	all praise and all curses will be directly forwarded to him.
      </p>
<p>
	GObject's memory management model was designed to be easily integrated in existing code
	using garbage collection. This is why the destruction process is split in two phases:
	the first phase, executed in the dispose handler is supposed to release all references
	to other member objects. The second phase, executed by the finalize handler is supposed
	to complete the object's destruction process. Object methods should be able to run
	without program error (that is, without segfault :) in-between the two phases.
      </p>
<p>
	This two-step destruction process is very useful to break reference counting cycles.
	While the detection of the cycles is up to the external code, once the cycles have been
	detected, the external code can invoke <code class="function">g_object_dispose</code> which 
	will indeed break any existing cycles since it will run the dispose handler associated
	to the object and thus release all references to other objects.
      </p>
<p>
	Attentive readers might now have understood one of the rules about the dispose handler
	we stated a bit sooner: the dispose handler can be invoked multiple times. Let's say we
	have a reference count cycle: object A references B which itself references object A.
	Let's say we have detected the cycle and we want to destroy the two objects. One way to 
	do this would be to invoke <code class="function">g_object_dispose</code> on one of the 
	objects.
      </p>
<p>
	If object A releases all its references to all objects, this means it releases its
	reference to object B. If object B was not owned by anyone else, this is its last
	reference count which means this last unref runs B's dispose handler which, in turn,
	releases B's reference on object A. If this is A's last reference count, this last 
	unref runs A's dispose handler which is running for the second time before
	A's finalize handler is invoked !
      </p>
<p>
	The above example, which might seem a bit contrived can really happen if your
	GObject's are being handled by language bindings. I would thus suggest the rules stated above
	for object destruction are closely followed. Otherwise, <span class="emphasis"><em>Bad Bad Things</em></span> 
	will happen.
      </p>
</div>
</div>
</body>
</html>

Anon7 - 2021