libgcrypt 1.1.93 released
bbp at via.ecp.fr
Tue Mar 9 14:21:49 CET 2004
> Why no have a libgcrypt linked with both pthread and pth, but do no
> locking, unless explicitely requested. That is an application that
> uses pthread calls something like gcry_enable_pthread_locks() etc.
> Is this a viable solution?
It may be better to have a gcry_set_locking_function(), because some
multithreaded applications do not use pthread nor pth. For instance,
about a problem I have with gnutls, I had to develop a clone() based
hack. libgcrypt shouldn't have to bother with the specific threading
implemention the application uses, should it?
> Since the only non-reentrant part is the random generator, an other
> solution would be to add a thread safe random number generator api
> (ie return handle of a pool), so the only one bothered with
> locking is the application.
Why not simply read "/dev/urandom" on OSes where it is available?
More information about the Gcrypt-devel