Mark Phalan wrote:
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.
This is my point. This is possible even on Sparc without setting up threading, please don't spread such misinformation.
A quick google lands me http://developers.sun.com/solaris/articles/atomic_sparc/ maybe reading through this will help you see how that is done.
OpenSSL is already half way there with having universal ASM support (for crypto optimization) and I do not see anything wrong in it mandating a set of primitives be available and ported for any platform building OpenSSL (out the box) that also wishes to support threading.
Maybe the greatest issue and road block is backward compatibility, 1.0 was a chance to fix a lot of stuff. If you're going to break backward compatibility might as well improve a bunch of other stuff at the same time.
Darryl ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
