[gnutls-dev] Re: living without global variables

[Werner Koch]

On Wed, 28 Dec 2005 10:13:52 +0100, Simon Josefsson said:

> When we have a replacement for libgcrypt, we can reconsider this
> issue, and then I think it would even be possible to get a thread safe
> gnutls_global_init() -- the only remaining problem then would be the

Indeed, Libgcrypt requires a call to an init fucntion and has for
various reasons no deinit function.  This is due to the fact that
Libgcrypt deliberately keeps global state (modules, random pool,
self-tests, hooks, threading model).

We discussed these issues for a long time and the only way to make
Libgcrypt thread safe is by delegating the initialization to the
actual application - only the application knows what threading model
it is going to use.  Thus we use a macro to initialize the threading
and then to lock things down the road.  The proper way for other
libraries to use libgcrypt is by wrapping this init function and to
allow the caller to actually initialize Libgcrypt (hidden in a
wrapper function).  

Unfortunately gnutls does not do this.  Bryan's session group function
could be used to mitigate this problem as well.  However, this does
not solve the problem of "unloading" libgcrypt.  In fact Libgcrypt
should never be unloaded but kept in memory for the lifetime of the
process.  Libgcrypt's init code silently ignores re-initialization and
bails out only if the threading model is going to be changed.  There
are plans to get rid of the global state but this would involve
migrating some of the code out to a daemon.


Salam-Shalom,

   Werner