libgcrypt 1.1.93 released
nmav at gnutls.org
Tue Mar 9 15:08:19 CET 2004
On Tue, Mar 09, 2004 at 01:20:06PM +0100, Marcus Brinkmann wrote:
> We considered the situation, and the issue is fundamental. There is
> no solution we know of.
> First, the automatic thread detection was a fancy idea, but it isn't
> very portable and it is not very reliable either. You could get the
> linking wrong easily (esp with libtool) and had no way to know - there
> was no error detection at all.
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?
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.
Another solution would be for libgcrypt to fork a rng proccess,
and communicate using IPC with it. This would be certainly thread
safe (however this only works in systems with fork() available).
More information about the Gcrypt-devel