Hi,
Ok I got your point. I think it will be helpful.Do you have any link or
precedure to setup these call backs or these are just function pointers
which needs to be initialized at ssl initialization time.
Regards,
Alok
On Fri, Sep 23, 2011 at 5:22 PM, Dr. Stephen Henson <st...@openssl.org>wrote:
> On Fri, Sep 23, 2011, alok sharma wrote:
>
> > Hi,
> > The error message comes when we invoke SSL_accept() API. But taking
> > lock on it will affect performance as it performs network operation
> inside
> > this API (like client hello message and other). So if network is
> overloaded
> > then mutex hold time will be too large. I have observed that in worst
> case
> > it holds lock for around 5-6 mins.
>
> You don't lock the SSL_accept API.
>
> In an multithreaded application OpenSSL needs to use locks internally to
> avoid
> race conditions. In order to do this an application needs to supply a set
> of
> locking callbacks which OpenSSL makes use of internally. The locking times
> should always be very short for these cases: they are typically used to
> ensure
> reference counts are incremented and decremented properly. If you don't set
> these up OpenSSL will be unstable in multithreaded applications: one
> symptom
> of this is how the FIPS PRNG behaves.
>
> For more details see the archives and documentation. For example: the
> "threads" manual page.
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List openssl-users@openssl.org
> Automated List Manager majord...@openssl.org
>
