On 03/29/10 12:03 AM, Peter Waltenberg wrote:
Historically I suspect the reason there were no default callbacks is that a
sizeable proportion of OpenSSL users didn't use threading at all, and the
baggage hauling in the thread libraries imposed was significant.
I don't think that's an issue anymore - threading is the common case now.
But - there's another issue you've all missed. You can have multiple
independently developed libraries in the same process all using OpenSSL -
who gets to set the thread callbacks ?. They have to be set to ensure
thread safe operation, but no individual library can assume that "someone
else" has done it now.
Even better - a library does set the callbacks - and gets unloaded while
other libs are still using OpenSSL. (Not just a "what if" - that one I've
seen in the wild).
So - yes, you probably do need to set the callbacks by default now, and you
probably need to make that API a no-op as well.
I think making the API a no-op is probably not a good idea currently. I
recently saw an application (BIND) using the callbacks to gather
statistics. Breaking these sorts of applications is probably not
desirable. Also, if there are indeed performance issues as another
poster pointed out then it would be nice if applications had control to
re-set/disable the callbacks.
-M
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
