------=_Part_9902_589261.1201592815931
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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 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 majordomo@openssl.org
>


------=_Part_9902_589261.1201592815931
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

 

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 <lesanti@fiuba7504.com.ar> 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                       penssl-dev@openssl.org">openssl-dev@openssl.org
Automated List Manager                           majordomo@openssl.org




------=_Part_9902_589261.1201592815931--
__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org