On Fri, 2010-06-25 at 01:58 +0200, Ger Hobbelt via RT wrote: > The only critical bit here is opinion replacing analysis. > > As you said so yourself, and I quote: "When both an application and a > library ([...]) both initialize and register their own threading functions, > bad things happen and the application can crash.") > Indeed. Spot on, I'd say. > > That is /exactly/ why OpenSSL places the ability, and hence also the > responsibility [which is the evil siamese twin of 'ability'], to _provide_ > an singular set of locking operations to the OpenSSL library itself for its > use. > These are > CRYPTO_set_lock_callback > CRYPTO_add_locking_callback > CRYPTO_set_dynlock_create_callback > CRYPTO_set_dynlock_lock_callback > CRYPTO_set_dynlock_destroy_callback > and you must call those at library setup time, say, around the same time you > invoke ERR_load_crypto_strings().
Except setting up locking at library setup time is inherently racy and *cannot* be done safely. The *only* safe place to setup locking callbacks is from the application. libraries cannot safely setup the locking callbacks. Just to make it clear why this is a problem imagine two threads running on Solaris each concurrently dlopening a plugin. Each plugin is linked against OpenSSL and tries to be a good citizen by setting the locking callbacks. They have no way to synchronize and thus no way to avoid racing against each other. As was noted elsewhere in the thread at least OpenSSL needs to provide way to safely (I think atomic test and set was mentioned) set the locking callbacks. I think it would also be nice if OpenSSL could have a compile time option to set default locking operations using the native threading model for the platform its being compiled on. I imagine that for most of the Linux/Unix/BSD etc this would be desirable. -M ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
