Peter Waltenberg wrote: > Document that this can only be done from the top level executable NOT > from > a shared library - and the top level app can switch the lock model if > it > wants. Changing the locking model is something that really can only be > done > by whatever owns main() anyway - it's not something that can ever be > safe > in a shared library.
With a newly-designed API, It could be made safe and, at least in some cases, it could be needed. What if the default callbacks in OpenSSL are completely unsuitable for the threading model the application is using, and the application was never designed with OpenSSL in mind? The only fix that doesn't require changing the application to be OpenSSL-aware is for a library to be able to change the OpenSSL threading model. One way would be a new call that allows a library or application to spin up the OpenSSL callbacks. New OpenSSL-using programs would call this function before they do anything with OpenSSL and also de-register before they unload. They could set the default callbacks or point OpenSSL to a shared library that it would load for custom callbacks. Additional OpenSSL-users would be told that OpenSSL was already initialized appropriately for the threading model the application uses. On de-register, the reference count would be dropped. If OpenSSL dropped to zero, it could unlock the custom callback library and itself, if desired. For existing code, I still think the best solution is to ignore any attempt to change the OpenSSL threading model callbacks but to report success. The one exception would be allowing one change if no OpenSSL functions have yet been called. The default could be left as is or could be callbacks that are safe for the platform's default threading model -- I don't have a strong feeling one way or the other about that as I haven't surveyed what existing OpenSSL-using programs actually do. The existing calls would have to be deprecated. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
