Revert the patch for bug 527214 and related changes. GTimer

is supposed to work without threads.


svn path=/trunk/; revision=6943

docs/reference/glib/tmpl/threads.sgml

@@ -162,20 +162,22 @@ the thread system by calling g_thread_init(). Most of the time you
 will only have to call <literal>g_thread_init (NULL)</literal>. 
 </para>
 
-<note>
-<para>
+<note><para>
 Do not call g_thread_init() with a non-%NULL parameter unless you
 really know what you are doing.
-</para>
-</note>
+</para></note>
 
-<note>
-<para>
+<note><para>
 g_thread_init() must not be called directly or indirectly as a
 callback from GLib. Also no mutexes may be currently locked while
 calling g_thread_init().
-</para>
-</note>
+</para></note>
+
+<note><para>
+g_thread_init() changes the way in which #GTimer measures elapsed time.
+As a consequence, timers that are running while g_thread_init() is called
+may report unreliable times.
+</para></note>
 
 <para>
 g_thread_init() might only be called once. On the second call

docs/reference/glib/tmpl/timers.sgml

@@ -11,8 +11,10 @@ This is done somewhat differently on different platforms, and can be tricky to
 get exactly right, so #GTimer provides a portable/convenient interface.
 </para>
 <note><para>
-#GTimer internally uses the threading API. Therefore g_thread_init() has to be
-called before creating #GTimer instances.
+#GTimer uses a higher-quality clock when thread support is available. 
+Therefore, calling g_thread_init() while timers are running may lead to
+unreliable results. It is best to call g_thread_init() before starting
+any timers, if you are using threads at all.
 </para></note>
 
 <!-- ##### SECTION See_Also ##### -->
@@ -34,9 +36,6 @@ Opaque datatype that records a start time.
 Creates a new timer, and starts timing (i.e. g_timer_start() is implicitly
 called for you).
 </para>
-<note><para>
-Call g_thread_init() before using this function.
-</para></note>
 
 @Returns: a new #GTimer.