Gratuitous gcry_fast_random_poll
Werner Koch
wk at gnupg.org
Wed May 5 19:35:53 CEST 2004
On Mon, 3 May 2004 23:52:52 -0500, Christian Grothoff said:
> concurrent use). Now, we can fix it by doing more (useless) locking in
> GNUnet (will patch), but I'll CC this to libgcrypt-devel since I believe they
> should avoid doing such calls that require locks on paths that one would
> commonly not consider accessing the random-pool or other global
> datastructures.
This call to fast_random_poll() is there on purpose as the comment
describes. Without that people will very likely forget to add a
couple of poll clals and we better make sure that they are at least
used from time to time.
I don't know what you mean by locking though. If you are using a
multi-threaded application you need to make sure that libgcrypt is
porperly initialized - see the section in the manual.
>> > gnunetd: ath.c:181: _gcry_ath_mutex_lock: Assertion `*lock ==
>> > ((ath_mutex_t) 0)' failed.
May it be that another library you link to uses pthreads and you don't
know about this. libpcsclite for example does this.
Werner
More information about the Gcrypt-devel
mailing list