Having read posts from this thread, I'd like to bring a few comments as a casual OpenSSL user.
My feeling is that OpenSSL approach to locking is quite different from other libraries and poorly documented. Combined, these two facts have caused most of our developers to completely miss the locking callbacks, even though they are working on a multithreaded application. - The documentation about the lock callback is deeply buried and not clear. Such an important point as thread-safety should surely be one of the first documented points instead of being buried and scattered in the documentation. - Even when aware of the lock callback mechanism, most of these developers assumed that the library was providing a default implementation. Only reading and testing the actual code proved otherwise. Again, the documentation should be made more explicit. As some people have already mentioned, the fact that an application may use OpenSSL indirectly via one or several 3rd party libraries doesn't help (we've also experienced it, and I'll quote one member of our team in saying that it was "a total cluster fuck"). Considering all of the above, I think that the current OpenSSL design regarding locking is imperfect as it diverges too much from your typical library (and the developer's expectations). IMHO: 1/ Most developers expect a default implementation, and OpenSSL should provide it. 2/ The API should be simple for the majority of use cases, and be complex when things need to be complex. 3/ Documentation, documentation and documentation. I don't buy too much into the performance argument. Most modern locking implementation are actually quite fast as long as there is no thread contention; therefore a single threaded application pays little performance for the locking. Plus, if you care about performance, you're likely going to go multithreaded (you wouldn't want all those cores on your CPU to go unused?). Nowadays, most common platforms assume that an application is to be multithreaded by default (or even provide this as the only choice, for example there has not been a single-threaded runtime on Visual C++ for quite a while). In that regard, providing a default locking callback on most platforms seems like quite a sensible choice to me. The default callback not always being the most suitable in all cases, yes you should be able to change it (cf. point 2). Regards, Tanguy -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Mark Phalan Sent: 25 March 2010 1:14 PM To: [email protected] Subject: libcrypto safe for library use? The threads(3) manpage states that to use OpenSSL in multi-threaded applications then locking callback functions must be set otherwise random crashes may occur. This poses a challenge when using OpenSSL in a library which should be MT safe. There is no safe way to set the locking callbacks from within the library itself. The calling application may or may not be using OpenSSL or may be linking against multiple libraries some of which may be linked against OpenSSL. The application may not even be aware that it will end up calling into OpenSSL code. The only safe way to ensure that the OpenSSL code will be MT safe would be for the OpenSSL library itself to set locking callbacks, however I don't see any compile-time option to do that. Is there a reason I'm missing as to why this option isn't available? Without this, the library can do its best to set the locking callbacks when loaded if they are not set and then remove them when unloaded, however this will always be inherently racy if there are other parts of the process using OpenSSL. Thanks, -M ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected] ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
