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

[Andy Lutomirski]

On Fri, Nov 29, 2013 at 3:43 PM, Nikos Mavrogiannopoulos
<nmav at gnutls.org> wrote:
> 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
> out]
>
>> >> 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.

Windows has an InitOnceInitialize, etc mechanism (on Vista and higher).

In any case, getting this right on pthreads systems would be a major
improvement over getting it wrong everywhere.

--Andy