Thanks. I added those details to the commit message and pushed the fix.
John Darrington <j...@darrington.wattle.id.au> writes: > 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 <j...@darrington.wattle.id.au> 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 > > pspp-dev@gnu.org > > https://lists.gnu.org/mailman/listinfo/pspp-dev _______________________________________________ pspp-dev mailing list pspp-dev@gnu.org https://lists.gnu.org/mailman/listinfo/pspp-dev
