[gnutls-devel] Automatic library initialization
Tim Rühsen
tim.ruehsen at gmx.de
Thu Nov 26 22:00:07 CET 2015
Am Dienstag, 24. November 2015, 17:06:41 schrieb Andrew W. Nosenko:
> On Tue, Nov 24, 2015 at 2:45 PM, Nikos Mavrogiannopoulos <nmav at gnutls.org>
>
> wrote:
> > On Tue, Nov 24, 2015 at 10:38 AM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> > >> It was included in the 3.4.x and 3.3.x releases, but this option must
> > >> be used with extreme care. Even though you may know where in your
> > >> application gnutls usage starts, you may not know whether some library
> > >> that you use will use it. You may not know for example that getpwnam()
> > >> will end up requiring to call gnutls in some setups. For that it
> > >> should not be used lightly as you'll rediscover the bugs that the
> > >> initialization to constructor was solving.
> > >
> > > Thanks for pointing out (I wasn't aware of getpwnam pulling in gnutls).
> > > As far as I can see, on (most ?) multi-threaded environments
> > > gnutls_global_init is thread-safe via GNUTLS_STATIC_MUTEX* !?
> > > If a system offers multi-threading, it will also offer mutexes/locks
> > > that
> > > could/will be used by gnutls. What am I missing ?
> >
> > [replying again on list]
> >
> > It would be safe only if the library that uses gnutls calls
> > gnutls_global_init() explicitly. If it relies on it being called on a
> > constructor you'll run into issues.
>
> No, because library doesn't know and has no way to know whether process
> spawned some threads already or not.
That is why gnutls_global_init() has been made thread-safe.
It doesn't matter if the process spawned threads or not.
Tim
More information about the Gnutls-devel
mailing list