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]
