Hi, I have implemented the static callbacks provided by OpenSSL for thread safety issue. After implementing the callback the performance of my program degraded drartically since this callback is issued from lot of places while accepting a new connection. This callback is issued nearly 200 times from files like ex_data.c , ssl_cert.c,md_rand.c,tasn_utl.c, err.c, t1_srvr.c, ssl_sess.c, ssl_lib.c, s3_lib.c, rsa_eay.c, rsa_lib.c, x509_vfy.c, x509_lu.c, bio_lib.c, by_dir.c, x_pubkey.c, p_lib.c etc.
Can any body please confirm that these callbacks will be issued this many times? Also can any one please suggest a way to provide the thread safety with out much impact in the performance. regards, S. Kingston Smiler. On Sep 5, 2007 4:53 PM, Kyle Hamilton <[EMAIL PROTECTED]> wrote: > Lock your app data separately from the lock that OpenSSL uses to > protect its own stuff. Don't manipulate the OpenSSL structures > directly, though if you've got reason to lock your application data > you can include the OpenSSL structures in your own locking. > > lock(appdata) > (call into openssl) > openssl->lock(ssldata) > <whatever openssl does internally> > openssl->unlock(ssldata) > (return from openssl) > unlock(appdata) > > But: don't give openssl's lock registration access to the same lock > that your app will be using. If it's a mutex (1-holder semaphore), > the way most locks should be, then what will happen is this: > > lock(appdata) > (call into openssl) > openssl->lock(ssldata) > /* lock already held, fails */ > > If you do this, then semantically the locking will operate properly > no matter what happens in the library or in your app. > > Give OpenSSL its locking. This will ensure that later semantic > changes to the library (as an example -- and note that I'm not on the > devteam, so I have no information on whether this will happen or not > -- an 'iterate over all connections' primitive that operates from any > thread, or an inspector for the state of any given SSL structure) > won't end up trying to access an application-locked but openssl- > unlocked structure. > > -Kyle H > > > On Sep 5, 2007, at 1:52 AM, Kingston Smiler wrote: > > > Hi, > > > > Thanks for your input. AFAIK registering these callbacks will result > > in locking the SSL datastructures internally by the OpenSSL whenever > > required. My question is since I've handled these in my application is > > it necessay for me to register these callbacks once again to the > > OpenSSL. I'm handling this in application becoz i've to save some more > > datas in the application scope from multiple thread access. So I've > > taken a lock and using the same lock I'm trying protect the SSL > > datastructures also. > > So I this case is it necessary to register once again into the > > openSSL. > > > > regards, > > S.Kingston Smiler. > > > > On 9/5/07, zhuxian <[EMAIL PROTECTED]> wrote: > >> Hi, > >> > >> I think you needn't lock the SSL_connect/SSL_accept. It's too low > >> efficient. > >> > >> > >> You just have to set the lock callback using: > >> > >> CRYPTO_set_locking_callback(pthread_lock_handler); > >> > >> CRYPTO_set_id_callback(id_handler); > >> > >> It works fine in linux. But it does not in WinXP. I was puzzled > >> with it > >> too. > >> > >> Regards, > >> Kurt. > >> > >>> -----Original Message----- > >>> From: [EMAIL PROTECTED] > >>> [mailto:[EMAIL PROTECTED] On Behalf Of Kingston > >>> Smiler > >>> Sent: Wednesday, September 05, 2007 3:53 PM > >>> To: openssl-users@openssl.org > >>> Subject: Reagrding Thread safety in OpenSSL > >>> > >>> Hi, > >>> I'm having a small query regarding the thread safety of the > >>> OpenSSL library. > >>> OpenSSL provide some set of Static Locking Callbacks and > >>> Dynamic locking callbacks to ensure the thread safety of the > >>> OpenSSL data structures. But if the application using the > >>> OpenSSL, implements its own locking mechanism while accessing > >>> the SSL calls (SSL_Connect,SSL_Read e.t.c) then is it > >>> necessary to implment those callbacks also? > >>> > >>> i.e > >>> > >>> code like this > >>> > >>> Thread1 > >>> { > >>> > >>> lock (a) > >>> SSL_Connect(pSSL) > >>> unlock(a) > >>> > >>> } > >>> > >>> Thread2 > >>> { > >>> lock (a); > >>> SSL_accept(pSSL); > >>> unlok(a); > >>> } > >>> ____________________________________________________________________ > >>> __ > >>> OpenSSL Project http:// > >>> www.openssl.org > >>> User Support Mailing List openssl- > >>> [EMAIL PROTECTED] > >>> Automated List Manager > >>> [EMAIL PROTECTED] > >>> > >> > >> > >> _____________________________________________________________________ > >> _ > >> OpenSSL Project http:// > >> www.openssl.org > >> User Support Mailing List openssl- > >> [EMAIL PROTECTED] > >> Automated List Manager > >> [EMAIL PROTECTED] > >> > > ______________________________________________________________________ > > OpenSSL Project http://www.openssl.org > > User Support Mailing List openssl-users@openssl.org > > Automated List Manager [EMAIL PROTECTED] > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager [EMAIL PROTECTED] > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
