On Mon, 14 Jan 2013, paul_curl_at_brainspark.nl wrote:

> But calls for entropy from the pool (called entropy_func()), should be
> thread-safe. So we need to guarantee thread-safety there. :(..

Oh, yes that is an issue. I guess that's the kind of place where OpenSSL and
gcrypt and friends invoke their mutex callbacks...

> - Connection specific entropy pool (possibly worse entropy per connection,
> but no thread-issues)
> - Force pthread use for mutex locks in curlssl_init()
>
> What are your thoughts on this?

Can't you also build PolarSSL for Windows? Then it needs to be pthread+win32
mutex code...

But honestly I don't think I can make this judgement. I don't really know the
level of impact the worse entropy would get in a per-connection pool, but I
also don't think a pthread/win32 mutex for people who build with PolarSSL
support is a blocker. I think I will have to leave that to you, unless someone
else speaks up on this.

>> If you make sure the define called curlssl_init in lib/polarssl.h

> Ok. Thanks. Had not noticed that init function yet. How is tear-down /
> free-ing handled (e.g. the mutex)? Or is it ok to leave things?

The curlssl_cleanup() function is called from curl_global_cleanup() and should
cleanup what curlssl_init().

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html