On Mon, Mar 29, 2010 at 12:03 AM, Peter Waltenberg <pwal...@au1.ibm.com>wrote:
> I don't think that's an issue anymore - threading is the common case now.
>
common case != everybody
>
> 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).
>
Even if OpenSSL would submit to your wish, then that would /not/ fix your
failure scenario above. At least not for everybody who needs to replace that
'default implementation', whatever it will be.
The proper way to fix that kind of conundrum (at least one of the ways and
IMO the most feasible for OpenSSL) is to allow callers (= other libs and app
using OpenSSL) a way to replace-and-restore those callbacks. push and pop if
you will, but I'd rather see that bit of management done by the outside
world (from the perspective of OpenSSL as a highly portable lib).
So that would be an API where you either
a) have an extra API function which delivers the references to the currently
installed callbacks (NULL if none are set up), or
b) a kinda signal() style API function set up where the function which is
used to register those callbacks with OpenSSL returns a reference to the
previously installed callback.
Both ways allow for multiple independent setup and termination
implementations like this (for style (b)):
init:
global f *old_callback_ref = CRYPTO_set_lock_callback(my_lock_func);
... // do thy thing, lib/app
exit:
// restore original:
CRYPTO_set_lock_callback(old_callback_ref);
and the only thing that needs to be changed for style (b) is the return type
of CRYPTO_set_lock_callback and friends (i.e. the dynlocks):
void CRYPTO_set_locking_callback(void (*locking_function)(int mode,
int n, const char *file, int line));
--> e.g.
typedef void CRYPTO_userdef_locking_function(int mode,
int n, const char *file, int line);
CRYPTO_userdef_locking_function *
CRYPTO_set_locking_callback(CRYPTO_userdef_locking_function *new);
which is at least compile-time backwards 'compatible' as current code
expects a 'void' return type for this API.
> So - yes, you probably do need to set the callbacks by default now, and you
>
Nope. Doesn't solve anything. (Maybe 'solves' -- on /some/ platforms --
'weird issues' happening to those, em, programmers who don't check sample
code or read man pages and forget about those locks altogether, but that's a
whole 'nother subject matter.)
My 2 cents, donated to the cause.
--
Met vriendelijke groeten / Best regards,
Ger Hobbelt
--------------------------------------------------
web: http://www.hobbelt.com/
http://www.hebbut.net/
mail: g...@hobbelt.com
mobile: +31-6-11 120 978
--------------------------------------------------
