cURL / Mailing Lists / curl-library / Single Mail


RE: Multi-thread initialization

From: <>
Date: Mon, 14 Jan 2013 17:24:40 +0100

> > PolarSSL functions are thread-safe as long as the contexts are only
> > used in a single thread at a time.
> That sounds like the same restrictions the curl handles have. They must
> be used by one thread at a time - but libcurl itself does nothing to make
> this is true but relies completely on that the application does the right
So that is identical for both libraries.

For the entropy-pool that is used within PolarSSL, it is advisable to just
make a single one as otherwise you are stripping your system of entropy and
possibly not having enough entropy in each pool.
> You'd then assume that the user of libcurl uses pthreads, which no default
> libcurl code does. I'm not sure that's a problem, I'm mostly just stating
> here...
Yeah.. We'd like to prevent that.

> > In our opinion the curl_global_init() function would be the best
> > choice, but maybe a separated file or function call is desirable.
> curl_global_init() is actually already documented as not thread-safe and
> must only be called from a single thread so you shouldn't need to protect
> with mutexes.
For the entropy pool entropy_init() this solves the thread-issue.

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

So the options are:
 - 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?

> If you make sure the define called curlssl_init in lib/polarssl.h is
updated to
> call a suitable new function for this purpose within lib/polarssl.c it
> need much more changes than so I believe.
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?

Lead Maintainer for PolarSSL SSL Library (

List admin:
Received on 2013-01-14