RE: multithreading question
Victor Duchovni wrote: 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. Locking callbacks are required, period. If you are using OpenSSL with multiple threads, you must have locking callbacks. These read-only operations modify reference counts... Right, that's what I mean by notionally read-only. They behave as if they were read-only, thanks to OpenSSL's internal locking. This is pretty much how every library that supports multi-threading works. Operations that are notionally read-only are made to act as if they were in fact read-only through internal locks in the library. So you can drop-in replace a copy-on-write string class for a normal string class without having to worry that a string may be modified by a modification to another string while you're trying to read it -- the library fixes that for you. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
multithreading question
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. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: multithreading question
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. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: multithreading question
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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
