On 21 Jun 2013, at 15:23, Nick Mathewson <[email protected]> wrote: […] > I was wondering whether it might not make more sense to have the > global structure be the one that gets locked, and the struct variant > be the unlocked one, so that we can avoid the extra lock overhead by > nesting it inside the existing structure locks.
Yeah, that makes more sense. So, the lock for an evutil_secure_rng would be that of its parent evdns_base, thus eliminating the need for locks on individual evutil_secure_rng contexts? Though it does mean that multiple threads cannot use a standalone evutil_secure_rng without providing their own locking, but that functionality is probably not needed. So, is it safe to simply remove the locks from the evutil_secure_rng contexts and rely on those of their evedns_bases, or do some changes need to be made at the evedns_base level? > > Two minor things that I spotted while skimming: > * <inttypes.h> isn't standard, and (sadly) <stdint.h> isn't > universal. We define reasonable replacements in event2/util.h, > though. Thanks! > * We don't want to declare our own non-static functions with the > same names as library functions if we can help it; it can get > confusing. To be honest, I wasn't really happy with the _r convention I adopted for the new context-based evutil_secure_rng_get_bytes, etc, functions, but I didn't want to get bogged down in mnemonics. Do you think evutil_secure_rng_get_bytes_r, etc, should be part of a the external interface, or just internal? If external, what kind of name would you give them? > (Also, by convention, if a name is exported by a module > but it isn't a public API of libevent, we suffix it with a _) OK, so you'd like arc4random_buf_r to become arc4random_buf_, for example? Thanks for your great feedback! *Joe *********************************************************************** To unsubscribe, send an e-mail to [email protected] with unsubscribe libevent-users in the body.
