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,
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;
>
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_
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);
On Sun, Sep 04, 2005, Jrgen Hovland wrote:
> Hi,
>
> I have a question about the use of openssl, EVP_CIPHER_CTXs, in a
> multithreaded environment.
> I have N threads calling a function that contains an EVP_CIPHER_CTX,
> ctx_init, EVP_CipherUpdate/Final and then Cleanup.
> The CTX is only used by
Hi,
I have a question about the use of openssl, EVP_CIPHER_CTXs, in a
multithreaded environment.
I have N threads calling a function that contains an EVP_CIPHER_CTX,
ctx_init, EVP_CipherUpdate/Final and then Cleanup.
The CTX is only used by that same thread calling the function.
Must all N thread
