Re: GNOME CVS: glib martin

[otaylor fresnel labs redhat com]

Martin Baulig <martin home-of-linux org> writes:

> otaylor fresnel labs redhat com writes:
> 
> > gnomecvs cvs gnome org (Gnome CVS User) writes:
> > 
> > > CVSROOT:	/cvs/gnome
> > > Module name:	glib
> > > Changes by:	martin	00/09/29 18:18:56
> > > 
> > > Modified files:
> > > 	.              : ChangeLog configure.in Makefile.am 
> > > 
> > > Log message:
> > > 2000-09-30  Martin Baulig  <baulig suse de>
> > > 
> > > * configure.in (HAVE_THREADS): New automake conditional.
> > > * Makefile.am (SUBDIRS): Only compile the gthread subdirectory if we
> > > actually have threads.
> > 
> > Please don't commit this sort of stuff without asking first; this
> > was all set up to work the way it does for GLib-1.2 after much
> > discussion.
> > 
> > Could you please mail gtk-devel-list, CC'ing Sebastian Wilhelmi
> > <wilhelmi ira uka de> and explain exactly what you changed and
> > why?
> 
> I'm sorry about this.
> 
> Well, it seemed very logical to me that if either the OS doesn't have any
> thread support of if the user disabled thread support with --disable-threads
> then it makes no sense to compile the gthread library.
> 
> The automake conditional disables the gthread directory from being built if
> either
> 
> a) "$have_threads" is "none" after all the thread checks - in this case the
>    OS doesn't have any thread support
> b) "$want_threads" is "no" - in this case the user manually disabled thread
>    support for some reason which should be honored.
> 
> AM_CONDITIONAL(HAVE_THREADS, test "x$have_threads" != xnone && test "x$want_threads" != xno)
>
> If we do not want to disable the gthread directory even if there's no thread
> support at all on the system for some reason, we should at least do it if the
> user specified --disable-threads to avoid that it breaks compilation on a
> system (such as Tru64 for instance) where this simply doesn't work.
> 
> Again, sorry for not asking first.

To see why this is wrong, first consider the differnce between 
--disable-threads and --without-threads

 --disable-threads: Completely omit all thread locks
 --without-threads: Do not use the system implementation of threads
                    but put in the thread locks, and allow an
                    implementation of the locks to be supplied at
                    g_thread_init() time.

So, as long as the user has not disabled thread support with
--disable-threads, we need -lgthread so that g_thread_init()
is provided.

However, even with --disable-threads, I'm not sure disabling
building -lgthread is appropriate; one principle we try to follow
with GLib/GTK+ is that the set of exported symbols does not change
with configure options. Of course, it's a rather silly library
just two function calls, that look like:

g_thread_init (GThreadFunctions* init)
{
  gboolean supported;

#ifndef G_THREADS_ENABLED
  g_error ("GLib thread support is disabled.");
#endif  /* !G_THREADS_ENABLED */
[..]
}

But still, I'd rather it die with a runtime error (though g_error()
is really not appropriate here) than have g_thread_init() not
appear at all.

I don't see why building the -lgthread library should break
compilation on any platform. If no system thread support is
found, the library will just be a stub. Sure, building it
is not necessarily quite as efficient as omitting it, but 
I don't care that much about streamlining the uncommon
case where it doesn't need to be built.

Regards,
                                        Owen

[ 
 Actually, we could move g_thread_init() into glib.h when there is no
 system implementation - the reason it is normally a separately
 library is so that we don't have to link every GLib library against
 the system thread support libraries. But as above, this is a
 miniscule optimization of the uncommon case, and just makes it
 more likely that this case will be accidentally broken, since it
 is more different code than leaving a separate -lgthread.
]