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

[Nico Williams]

On Fri, Nov 29, 2013 at 5:46 PM, Andy Lutomirski <luto at amacapital.net> wrote:
>> 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.

+1 to all of what you say Andy, but I'd like to add:

1) If you have enough basic primitives (like mutexes with static
initializers, or mutexes and CAS, or InitOnceInitialize), then you can
self-initialize in a library safely.

2) Every major OS/architecture has the primitives needed for library
self-initialization.  There is no excuse not to self-initialize
libraries safely.

3) Every major current OS/architecture has (and has had for a long
time) default threading primitives (e.g., pthreads) and atomic
operations (e.g., CAS).  There is no need for allowing apps to provide
their own lock callbacks as in OpenSSL (although it's possible to make
that work, provided that the callback-setting interface is not
inherently thread-unsafe).

4) DO NOT USE ELF .ini sections for thread-safe initialization, not if
the .init section has any dependencies on any other objects/libraries
than the C run-time.  There's no canonical ELF .ini section load/run
order.  On Windows you might use DllMain, but I wouldn't -- just build
portable once-init infrastructure and use it everywhere.

Nico
--