Re: GStaticMutex

[Drazen Kacar <dave srce hr>]

otaylor redhat com wrote:

> Since 
> 
>  pthread_mutex_initializer_t mutex = PTHREAD_MUTEX_INITIALIZER;
> 
> Is defined to work for static initialization, and static initialization
> in C is pretty strictly limited, what GLib does is quite safe.

OK. I thought PTHREAD_MUTEX_INITIALIZER could be a function call, but
it can't.

> Now, yes, its conceivable that PTHREAD_MUTEX_INITIALIZER would
> contain pointers to load-resolved linker symbols. 

> If we run into a platform where that is the case, we will
> fix GLib on that platform. But since POSIX guarantees that mutexes
> can be statically initialized, such a fix _will_ be possible.

GLib is not limitted to POSIX only platforms. If you run into such
platform, it doesn't have to be possible. This is nit-picking, though.

> (The reason for the configure hack is to avoid including pthread.h 
> in glib.h, that and nothing more.)
> 
> And the reason that static mutex initializers are a good thing is not
> because of a few calls to pthread_mutex_init() called, but because
> they avoid race conditions with initializing mutexes.
> 
> Alternate methods of dealing with that are either uglier or less
> portable, or both.

It's usually the code in .init section (or equivalent). Getting there
isn't portable at all, but it's more powerful in case you need a few
more things. Avoiding the need for g_thread_init() would be one of them,
but it's not worth the effort if it's just that.

> Feel free not to use GLib, but if you do that, please do it for
> a valid reason.

I suppose I got what I asked for. :-)

-- 
 .-.   .-.    I don't work for my employer.
(_  \ /  _)
     |        dave srce hr
     |        dave fly srk fer hr