Rich Salz wrote:
> What is the problem you are trying to solve? Who has asked for it?
Inquiring minds want to know.
To play devil's advocate, why don't we get rid of all locks in OpenSSL?
Let's say we split OpenSSL into the classic API, which would consist of
a wrapper that was careful to lock everything that might be needed
for the current call, and an underlying "caller responsible for thread-safety"
layer where
* only one thread at a time would be allowed to access a particular session object
* no lazy initialization would be performed; the app would be required
to initialize OpenSSL in the main thread during startup.
* no static variables in OpenSSL; everything should be accessed through
an object pointer.
That should get rid of just about every lock in the code,
except perhaps those to protect the heap, logging, and engine.
In my server, I'd be more than happy to switch to the 'caller responsible
for thread-safety' version of the API. I simply don't need OpenSSL to
protect my threads from shooting each other in the foot; all I need
is OpenSSL to be designed to let me avoid pointing the gun at my foot.
- Dan
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
