libgcrypt 1.1.93 released

[Nikos Mavroyanopoulos]

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.
Hello Marcus,
 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).

> Thanks,
> Marcus

-- 
Nikos Mavroyanopoulos