[gnutls-devel] [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed)

Nikos Mavrogiannopoulos nmav at gnutls.org
Sat Nov 30 00:43:12 CET 2013

On Fri, 2013-11-29 at 15:35 -0800, Andy Lutomirski wrote:

[This is clearly off-topic for the TLS working group so it was striken

> >> Initialization is not thread-safe in OpenSSL either.  This is a terrible
> >> thing.  It *can* be made thread-safe, so there's no excuse for it not
> >> being thread-safe.
> > Hello,
> >  I don't understand why this is an issue since it is documented. If a
> > function (like a global initialization function) is supposed to create
> > the mutexes for the rest of the library functions it cannot be expected
> > to be thread safe; at least in a portable way since static
> > initialization of mutexes is not a portable thing.
> >
> > Nevertheless, even if you really need to call a global initialization
> > function in every thread you create (I really don't see why), you can
> > simply call it in a locked mutex.
> No, I can't.  I occasionally use libraries, and those libraries in
> turn use GnuTLS.  Requiring those libraries to force their users to
> synchronize their initialization of GnuTLS sucks.

I don't quite understand by what you mean by synchronize. They don't
need to synchronize, they just need to initialize the library at an
early state.

> Any self-respecting pthreads implementation should implement
> PTHREAD_MUTEX_INITIALIZER in such a way that it constant-initializes
> its data, making it completely safe.  An even better solution would be
> to use pthread_once.

Unfortuntely that only works with pthreads. What about systems that
don't have static initializers for locks? Unfortunately we need a
consistent API for all the supported systems.


More information about the Gnutls-devel mailing list