Re: [PATCH] configure.ac: Link PSPPIRE explicitly against gthread.

[John Darrington]

OK.  I agree that the documentation is not easy to follow, but it
seems that calling g_thread_init cannot do any harm so long as
we do it early.

On Fri, May 04, 2012 at 11:16:02PM -0700, Ben Pfaff wrote:
     I added a call in the same commit that adds a call to
     g_timer_new() to main(), because of the following note in the
     documentation for GTimer:
     
         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.
     
     Separately, the documentation for threads in Glib says:
     
         Calling g_thread_init() with a NULL argument is somewhat more
         relaxed.  You may call any other glib functions in the main
         thread before g_thread_init() as long as g_thread_init() is
         not called from a glib callback, or with any locks held.
         However, many libraries above glib does not support late
         initialization of threads, so doing this should be avoided if
         possible.
     
         Please note that since version 2.24 the GObject
         initialization function g_type_init() initializes threads
         (with a NULL argument), so most applications, including those
         using Gtk+ will run with threads enabled.  If you want a
         special thread implementation, make sure you call
         g_thread_init() before g_type_init() is called.
     
     Taken together, it seemed to imply that I should call
     g_thread_init() before g_timer_new(), or the timer might be
     unreliable because glib would call it later for me.  But the
     documentation doesn't seem entirely clear to me.
     
     John Darrington <address@hidden> writes:
     
     > This looks fine to me.
     >
     > However, I feel obliged to ask the question why are we actually
     > calling g_thread_init.  The docs say this is necessary iff we are
     > calling GLib from more than one thread.  So far as I'm aware, we're
     > not doing that, are we?
     >
     > J'
     >
     > On Fri, May 04, 2012 at 09:33:32PM -0700, Ben Pfaff wrote:
     >      Seems to be required on OpenSUSE.
     >      
     >      Reported by Mindaugas.
     >      Bug #36396.
     >      ---
     >       configure.ac           |    3 +++
     >       src/ui/gui/automake.mk |    1 +
     >       2 files changed, 4 insertions(+), 0 deletions(-)
     >      
     >      diff --git a/configure.ac b/configure.ac
     >      index 7d33ca2..2f3a8da 100644
     >      --- a/configure.ac
     >      +++ b/configure.ac
     >      @@ -73,6 +73,9 @@ AC_ARG_WITH([gui],
     >       AM_CONDITIONAL([HAVE_GUI], 
     >                      [test "$with_cairo" != no && test "$with_gui" != 
"no"])
     >       if test "$with_cairo" != no && test "$with_gui" != "no"; then
     >      +  PKG_CHECK_MODULES([GTHREAD], [gthread-2.0], [],
     >      +    [PSPP_REQUIRED_PREREQ([gthread 2.0 (or use --without-gui)])])
     >      +
     >         PKG_CHECK_MODULES([GTK], [gtk+-2.0 >= 2.16], [],
     >           [PSPP_REQUIRED_PREREQ([gtk+ 2.0 version 2.16 or later (or use 
--without-gui)])])
     >       
     >      diff --git a/src/ui/gui/automake.mk b/src/ui/gui/automake.mk
     >      index 96209a0..a7cb1de 100644
     >      --- a/src/ui/gui/automake.mk
     >      +++ b/src/ui/gui/automake.mk
     >      @@ -74,6 +74,7 @@ src_ui_gui_psppire_LDADD = \
     >          src/libpspp.la \
     >          src/libpspp-core.la \
     >          $(GTK_LIBS) \
     >      +   $(GTHREAD_LIBS) \
     >          $(GTKSOURCEVIEW_LIBS) \
     >          $(CAIRO_LIBS) \
     >          $(LIBINTL) \
     >      -- 
     >      1.7.2.5
     >      
     >      
     >      _______________________________________________
     >      pspp-dev mailing list
     >      address@hidden
     >      https://lists.gnu.org/mailman/listinfo/pspp-dev

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://keys.gnupg.net or any PGP keyserver for public key.

signature.asc
Description: Digital signature