Hrgh. No, you don't init or terminate anything when you're already trying to
execute it from several threads; such init and termination should be done
before and after that.
When a lib (instead of the app itself) is using OpenSSL on its own and that
lib requires a certain approach it is probably coded to set it up. With an
OpenSSL API augmented a la style (a) it can do this safely, i.e.:
init:
if (get_callbacks() != NULL)
{
// flag this situation for termination time and leave those callbacks the
hell alone
}
When the app is using several such libraries and/or doing OpenSSL work of
its own, it should call the OpenSSL init and shutdown/termination APIs
itself to ensure it is set up during the entire lifetime of the app, no way
around that.
What OpenSSL /could/ do is provide a few bits and pieces so that
libraries/modules who think they should be responsible for setting up and
shutting down OpenSSL themselves can check whether someone has done so
already beforehand and change their own actions accordingly; preferably by
leaving the setup alone. Indeed, wrong words by me 'push and pop'; it ain't
a stack.
The 'was OpenSSL set up already? And in a way we expect/require?' check has
to be performed in such [third party?] modules/libraries, at least in
modules/libs who would attempt to init/shutdown OpenSSL on their own.
What OpenSSL init/shutdown code /could/ do to help is maybe 'count' the
number of init and shutdown invocations and only really act on the first
one.
And setting up the callbacks counts as individual pieces of init code, so
they might be 'counted' individually (lock, dynlock, threadid).
That would fix this scenario:
On Mon, Mar 29, 2010 at 2:02 AM, Peter Waltenberg <pwal...@au1.ibm.com>wrote:
> You can't "push and pop" the callbacks.
>
> The software is running in multiple threads and being used by multiple
> independently developed libraries at the same time.
>
------
Do you really plan to swap the thread locking mechanism - (which is
> protecting you while you swap the locking mechanism around) while threads
> are running ?.
>
Definitely not.
> We don't have that option with the thread callbacks - they must be set, but
> there's no safe way for multiple "users" in the same process to do that at
> present - all I'm suggesting is that you "fix" this in the same way the
> memory callback use is made safe.
>
When the case is init from multiple threads simultaneously, then the memory
callback setup isn't 'safe' for that kind of thing either (none would). It's
just that that particular init is almost never invoked by any 'users' as
malloc/free is a /very/ common answer there. pthreads or what have you
aren't so common so the locking callbacks are a different matter IMO.
The right way to do it is have the app set it up at init time, either
through calling the OpenSSL functions directly or through a module/lib's
'init/setup' API if that's the one 'responsible' for OpenSSL activity in
your application.
Just in case some lib developer takes matters in his own hands a bit too
much, a 'only first invocation matters' style of setup might be used for
these and other bits of OpenSSL setup.
Aw shucks, what am I blathering...
I just checked: ./crypto/cryptlib.c already offers everything you need,
style (a):
void (*CRYPTO_get_locking_callback(void))(int mode,int type,const char
*file,
int line)
{
return(locking_callback);
}
int (*CRYPTO_get_add_lock_callback(void))(int *num,int mount,int type,
const char *file,int line)
...
Well, the 'only first come is served' idea isn't in there, but that's not
needed as long as library (instead of application) developers make sure to
check that CRYPTO_get_locking_callback() API before they get all active
about it themselves :-)
It's just that it's not in the man pages on the web site yet, it seems. A
documentation patch perhaps?
--
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
--------------------------------------------------
