Questions about multi-threading

[Werner Koch]

On Thu,  6 Jul 2006 00:19, haypo at inl.fr said:

> (d) Would it be possible to make random() functions (eg.
> gcry_random_bytes() and gcry_create_nonce()) really thread safe? (can be
> called in two different threads at the same time and not block one the
> call until the first ends)

That is not possible.  Ramndom is a scare resource and trhus we
serialize access.  Having separate instances of the random pool makes
things actually slower, because they need to be really separate and
can share nothing, in particular not any entropy used as seed.

The latest libgcrypt from SVN features a random daemon which might
be helpful for you.  There is not much documentatiion yet and
definitely not well tested; you might want to try it out.  You need to
call gcry_control (GCRYCTL_USE_RANDOM_DAEMON, 1) tight after
gcry_check_version to enable use of the daemon - there is a fallback
to the internal RNG if the daemon is not running.

> (e) Why using REGISTER_(...); macro and not simply call them in a function
> like "gcrypt_global_init();"? Eg. "REGISTER_DEFAULT_DIGESTS" in
> cipher/md.c, it uses a mutex to check if digests are already registred or
> not. "REGISTER_DEFAULT_DIGESTS" is called in 7 different functions, but is
> it really needed?

The idea behind the module system is to allow interpreters to load new
algorithms on demand and thus full fledged locking is required.

I think that it is a bit over designed and we may drop this with the
next version.  I doubt that the module system is actually used very
often.  However, this will be an ABI break.


Salam-Shalom,

   Werner