On Mon, 14 Jan 2013, [email protected] 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
