[gnutls-devel] [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed)
Nico Williams
nico at cryptonector.com
Sun Dec 1 03:14:01 CET 2013
On Sat, Nov 30, 2013 at 3:08 AM, Nikos Mavrogiannopoulos
<nmav at gnutls.org> wrote:
> On Fri, 2013-11-29 at 18:10 -0600, Nico Williams wrote:
>> 4) DO NOT USE ELF .ini sections for thread-safe initialization, [...]
>
> Have you considered or tried using that approach in your branch of
> openssl and backed off? If dependencies are avoided it looks like an
> ideal fix, especially if you consider that a global initialization
> function would do much more than just initializing mutexes (e.g.
> precalculations or CPU type detection).
.init sections have all of these problems:
- they aren't standard (not part of POSIX)
- they're not necessarily available in static linking cases (after
all, they are not standard)
- they require more autoconf/source/build complexity
- the order in which dependencies are loaded and their .init sections
run is unstable -- you can help yourself a bit by having no
dependencies on anything other than -lc and -lpthread in your .init
section, but you can't help anyone else who has a dependency on your
library in their .init sections(!)
Whereas using pthread_once() and friends is all standard. You can
build a pthread_once/InitOnceInitialize out of mutexes if you have
static mutex initializers, and you can build those if you have CAS.
Besides, the once approach is elegant and lends itself well to doing
the Right Thing, which is: automatically and thread-safely
self-initialize.
Nico
--
More information about the Gnutls-devel
mailing list