[gnutls-devel] [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed)
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
> 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