cURL / Mailing Lists / curl-library / Single Mail

curl-library

Thread safety of curl_global_init (was Re:)

From: Dan Fandrich <dan_at_coneharvesters.com>
Date: Fri, 15 Feb 2008 10:45:45 -0800

On Fri, Feb 15, 2008 at 01:22:08PM -0500, McGarvey, Kevin wrote:
> I looked into the topic of mutithreaded usage of OpenSSL and from what I
> read, you have to call CRYPTO_set_locking_callback() and
> CRYPTO_set_id_callback(). I searched the curl source and I see an
> example program in /docs/examples/opensslthreadlock.c.
>
> It seems that if we, or the host program does this, we would be safe.
> Please comment.

Even if we assume that's sufficient to protect all OpenSSL calls from
reentrancy problems (and I don't know enough about OpenSSL to know the
answer to that), you still need to take care of these issues:

- What about all the other initialization calls done in curl_global_init?
Are they all thread safe?
- What if an app calls curl_global_init on its own, independent of
your plugin?
- Is it possible that you could be linking against a libcurl that uses
an SSL library other than OpenSSL? Is its initialization thread safe?
- What about platform-specific initialization calls (if your app is
cross-platform)? Are those thread safe (e.g. Winsock initialization)?
- What if you determine the answer to all those questions, then a user
updates his libcurl with a different version with a new non-thread-safe
initialization call?

This is why the documentation for curl_global_init is so restrictive--in
many situations you just can't know the answer to all those questions.

>>> Dan

-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved
Received on 2008-02-15