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