[gnutls-devel] Automatic library initialization

Andrew W. Nosenko andrew.w.nosenko at gmail.com
Tue Nov 24 16:06:41 CET 2015


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.

-- 
Andrew W. Nosenko <andrew.w.nosenko at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20151124/4f9596e2/attachment.html>


More information about the Gnutls-devel mailing list