Let's say you have 1600 clients. Let's say that you have 40 threads, and each thread handles 40 connections. Now let's say that each thread initializes it's own SSL_CTX structure.
The SSL_CTX structure contains most of the data required for SSL functionality. Because each SSL_CTX structure has one-and-only-one thread accessing it, there can be no contention within the SSL_CTX structure's data. The next question is "is there any OTHER data (i.e. global data) within the OpenSSL library that the threads may be accessing concurrently?". The answer is "YES there are a few of these." Now of this global data, there is that which is initialized once on startup, and thereafter is "read-only", and there is that which is constantly updated. The former data is not of concern. My investigation reveals that the instances of global shared data that are modified after startup are very few. These are handled in the list in my previous emails. Of what VALUE this is, is questionable, because, it has been pointed out that locking with such an application would have minimal overhead. Myself I LIKE the idea of my code crashing so I do EVERYTHING I can to encourage my programs to crash. Each program crash is an indication of my not understanding something about my program!! :-) Saying there "MAY be something dangerous about what I am doing" is a reason TO do it because, within that "MAY" is something I don't understand about the OpenSSL library. And I don't like working with libraries that I don't understand! :^) Further, on some systems you can't link with libpthread if you intend to use fork(). I have two builds of my software, one that does fork()ing and one that does pthread_create()ing. So I am trying to avoid having to have two installations of OpenSSL on every build platform. -paul On Jan 25, 2008 4:45 PM, Leandro Santi <[EMAIL PROTECTED]> wrote: > Tomas Mraz, 2008-01-24: > > So IMO what Paul Sheer is doing - disabling all locking in OpenSSL given > > that there won't be any static and/or global variables in the OpenSSL > > code called is 100% safe thing if the threads do not share any data > > manipulated within the OpenSSL library. > > As mentioned in the docs, multithreaded OpenSSL needs special > application support, period. Not providing this means you'll > get undefined/undesirable results. > > Old MySQL versios did try this approach (i.e. using the library > in an undocumented way). Perhaps it sort-of worked for them > while they developed the SSL support for the database engine, > but newer MySQL/OpenSSL combinations didn't work at all (for > example, MySQL-4.0.23a+OpenSSL-0.9.7c). They fixed it, albeit a > few years down the road. > > Separately, I'd suggest a different development approach: first, > implement OpenSSL locking support. Do some measurements, with > and without locking. I'd be interested to get some quantitative > evidence before proceeding with this thread. > > Leandro > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager [EMAIL PROTECTED] >
