Re: [Libevent-users] Is evthread_use_pthreads required for isolated evdns event_bases?

[Joseph Spadavecchia <joseph@xxxxxxxxxxx>]

On 21 Jun 2013, at 15:23, Nick Mathewson <nickm@xxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.