[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNUnet-developers] Re: Gratuitous gcry_fast_random_poll
From: |
Werner Koch |
Subject: |
[GNUnet-developers] Re: Gratuitous gcry_fast_random_poll |
Date: |
Wed, 05 May 2004 19:35:53 +0200 |
User-agent: |
Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) |
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
- [GNUnet-developers] _gcry_ath_mutex_lock, Glenn McGrath, 2004/05/03
- Re: [GNUnet-developers] _gcry_ath_mutex_lock, Christian Grothoff, 2004/05/03
- Gratuitous gcry_fast_random_poll (Was: Re: [GNUnet-developers] _gcry_ath_mutex_lock), Christian Grothoff, 2004/05/04
- [GNUnet-developers] Re: Gratuitous gcry_fast_random_poll, Marcus Brinkmann, 2004/05/22
- [GNUnet-developers] Re: Gratuitous gcry_fast_random_poll, Werner Koch, 2004/05/05
- [GNUnet-developers] Re: Gratuitous gcry_fast_random_poll, Marcus Brinkmann, 2004/05/22
- [GNUnet-developers] Re: Gratuitous gcry_fast_random_poll, Werner Koch, 2004/05/07