On Wed, Jan 20, 2010 at 07:55:35PM -0800, David Schwartz wrote:
>
> Wayne Feick wrote:
>
> > Our server does a raw socket accept first, and then spawns a thread for
> > each that brings up the ssl connection if applicable. The code flow is
> > like this:
> >
> > int fd;
> > SSL_CTX* ctx;
> > SSL* ssl;
> >
> > BIO* fdbio = BIO_new_socket((int)fd, 0);
> > BIO* bio = BIO_new_ssl(ctx, client);
> > BIO_push(bio, fdbio);
> > BIO_get_ssl(bio, &ssl);
> >
> > The SSL_CTX is shared across the multiple threads.
> >
> > My question is whether BIO_new_ssl() should be serializing so that only
> > one thread is instantiating an SSL instance at a time from the SSL_CTX.
> >
> > Wayne.
>
> The BIO_new_ssl operation is notionally a read-only operation on the
> SSL_CTX. So you do not need to synchronize access to the SSL_CTX so
> long as no other thread might be doing an operation on it that is not
> notionally read-only. So long as only BIO_new_ssl operations overlap on
> the context, no external locking is needed.
Locking callbacks are needed for the reference counting in the CRYPTO
library to not get messed up. Various bits of context are associated
withe the new SSL object by reference.
These "read-only" operations modify reference counts...
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
