Okay,
I guess I must "eat my hat" (as we say in french) and admit you're right on
the discussion about OpenSSL not providing a specific thread implementation.
Please correct me (again ;-) if I'm wrong here:
I understand that CRYPTO_set_locking_callback() and CRYPTO_set_id_callback()
must be called in the initialisation sequence of any Openssl application
going multithreaded. These functions initialize callback pointers in
cryptlib.c:
locking_callback = thread lock/unlock function
id_callback = thread ID function
Example of implementation for these callbacks in th-lock.c.
The OpenSSL code uses the locking function by calling CRYPTO_r_lock/unlock
or CRYPTO_w_lock/unlock, as in by_dir.c:
CRYPTO_r_lock(CRYPTO_LOCK_X509_STORE);
tmp=(X509_OBJECT *)lh_retrieve(xl->store_ctx->certs,&stmp);
CRYPTO_r_unlock(CRYPTO_LOCK_X509_STORE);
Those are macros to the CRYPTO_lock() function defined in cryptlib.c, which
uses the locking_callback pointer.
What is the purpose of add_lock_callback, and how should you use it? It is
not described in the "threads" man pages, I think. It seems to be used only
from p8_key.c (calling CRYPTO_add_lock).
----- Original Message -----
From: Richard Levitte - VMS Whacker <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, June 06, 2000 9:22 AM
Subject: Re: thread support and Memory leaks
From: "Richard Dykiel" <[EMAIL PROTECTED]>
richard.dykiel> Thanks, but a simple and silly question subsists:
richard.dykiel>
richard.dykiel> If we must call CRYPTO_set_locking_callback() and
richard.dykiel> CRYPTO_set_id_callback() to support multithreading,
richard.dykiel> why isn't it used by OpenSSL itself? It's used
richard.dykiel> only in some test code, not linked w/ OpenSSL.
Uh? Have you actually looked at what they do? Have you looked what
other parts of OpenSSL do with the result? Just to pick an example,
have you looked how CRYPTO_r_lock() works?
Of course, CRYPTO_set_locking_callback() and CRYPTO_set_id_callback()
are only directly used in the MT test programs that are part of
OpenSSL. Is there a reason they should be used in programs that are
strictly single-threaded?
richard.dykiel> Are the functions thread_setup() and thread_cleanup(),
richard.dykiel> implemented in th-lock.c, a good solution to the
richard.dykiel> problem? In this case, they should be blended into
richard.dykiel> OpenSSL to simplify our lives, IMHO.
They are a number of ways to do it, not just one, but that's not all.
When dealing with dynamically linkable libraries, it's better to have
the application tell OpenSSL what threading functions should be used,
or the application and the OpenSSL library might end up doing
threading differently, which is a sure way to put the application to
death. In the case of Windows, there's the issue of which version of
the C runtime library you use, with the same kind of mess as result
(IIRC... I'm not a windows hacker). And on some platform, we're
simply unable to know how threading will be done.
So, basically, to simplify our lives (as you so eloquently put it),
the way OpenSSL currently works is the best (IMHO). Note that other
libraries use the same approach, like for example the LDAP SDK, some
crypto hardware libraries, and PKCS#11 (to some extent).
Of course, we could provide the option of using "native threads"
(PKCS#11 does provide that option), but personally I see that as a big
possibility to get very obscure bugs if you're unlucky, and would
therefore opt for not using those.
--
Richard Levitte \ Spannv�gen 38, II \ [EMAIL PROTECTED]
Chairman@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47
Redakteur@Stacken \ SWEDEN \ or +46-709-50 36 10
Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, Celo Communications: http://www.celocom.com/
Unsolicited commercial email is subject to an archival fee of $400.
See <http://www.stacken.kth.se/~levitte/mail/> for more info.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
