Re: next round: glib thread safety proposal

[Owen Taylor <otaylor redhat com>]

Sebastian Wilhelmi <wilhelmi@ira.uka.de> writes:

> This is a multi-part message in MIME format.
> --------------481169F0E76821E03AE15CA3
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> 
> Hi,
> 
> after some discussion with Owen, I've now changed my mind for the n'th
> time (n >> 1) and will make yet another proposal:
> 
> The aims:
> 
> - make glib reentrant (dont build two versions, one reentrant, the other 
>   nonereentrant)
> 
> - don't make glib require any additional linking, because 
>   additional thread libs might contain unwanted startup code etc.
> 
> - don't overuse special features of the target os, compiler and assembler. 
>   (we will however not be able to do without them for convenience reasons,
>    say weak linkage)
> 
> - allow programs using glib to change the used mutex/condition 
>   implementation. This is desirable beacuse e.g. netscape comes with its
> own
>   thread lib.

I've had a chance to take a look at this now, and my general
impression is while the solution as implemented with weak
symbols and __attribute__ ((constructor)) is quite clever
and interesting, once you consider making it portable beyond
gcc and ELF, the complexity it introduces is a bit 
prohibitive.

My inclination then is to go with a simpler solution - the
default implementation (in terms of pthreads, or other
threads) is put into a tiny library, -lgthread, and
programs wanting to use the default implementation call
g_thread_init() as the first thing in their program.

 glib-config --libs gthread

then returns '-lglib -lgthread -lpthread', to allow
configure scripts to get the correct libraries
easily.

This solution is not incompatible with eventually doing
clever tricks with weak symbols to avoid the need for
another library, but I think it provides a simpler
system at a fairly small additional cost. Are there
any problems with this approach that I am missing?
 
[..]

> I only extended the interface, because, if gtk get a finer grained mutex
> use, there might arise the need for conditions, so I put them here right
> away. There is however no thread creation function etc. This should be
> done in a dedicated library or be added here later. We'll see.

I agree that is OK for a first step. Glib and GTK+ don't need
to be able to create threads to be thread-safe.
 
> Then of course there is an extra file gmutex.c, that implements the whole
> thing. There is a constructor function "__attribute ((constructor))", that
> tries to find out, if the symbols for the pthread implementations are
> defined and enters them into the g_mutex_functions_for_glib_use function
> table to provide some sane default. This however requires weak symbols. I
> have cut'n'pasted something from the glibc to achieve this and it is
> working here on solaris. we would have to add some code to configure.in
> though. The init functions could of course be extendened to automatically
> look for other implementations too. attached is the file gmutex.c and the
> patch to glib.h and Makefile.am. On platforms without weak symbols we
> could do the following: provide a macro: G_MUTEX_STANDARD_IMPLEMENTATION
> that provides a complete implementation of all functions (so we have a
> deferred binding of the offending symbols, only in application code, not
> in library code) and sets the function table accordingly.
>
> The whole thing
> happens only if weak symbols are not possible on this platforms, otherwise
> the macro is just empty. Thus If you include this macro somewehre at the
> toplevel in you program (but only in one module) in a multithreaded
> program using glib, you get all you want.
> 
> So do something like:
> 
> G_MUTEX_STANDARD_IMPLEMENTATION;
> 
> int
> main()
> {
>   /* working thread safe on platforms with and without weak symbols */
> }

I don't see how a single macro could do both of these (especially
in the absence of weak symbols). The user would have to call some 
function inside there main(), I would think, which brings us
back to g_thread_init().

Regards,
                                        Owen