Mark Phalan wrote: > 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.
That is correct. > 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. It's trivial -- adopt the same solution OpenSSL adopts. Have the application set your library's locking callbacks and you pass them onto OpenSSL. It won't matter then if you change the callbacks because you'd be changing them to what they already were or would be anyway. > 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. It can't do that, it has no idea what threading model the application is using. It would have no way to know whether the locks it provided were suitable or sensible. > Is there a reason I'm missing as to why this option isn't available? The library has no way to know what threading model the application that calls it is using. Only the application has this knowledge, so it's the application's responsibility to pass this to the library. > 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. I agree. Your library should impose a requirement on any application that uses it that it inform you of the threading model it's using so that you can use appropriate locking as well. Then you can set the OpenSSL locking callbacks (just pass them through) and there's no chance of a race or problem. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
