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]
