It's a thread from a few months ago. OpenSSL needs to establish a default thread model in many cases.
The one we (IBM) hit is composite apps. Multiple independently developed lumps of code thrown together - someone has to set the locks, but deciding who is a problem. We deal with it easily as we put a wrapper around OpenSSL and do it there, but that's not always an option.
The OS installed OpenSSL's should probably also use the OS default thread model by default for similar reasons.
There were also a number of cases of 'user error' with people just forgetting to set up the locking around that time.
That's the background.
I wouldn't consider efficiency a major problem as if it's a concern you still have the option of rolling your own fix, but nothing wrong with improving it, I'd suggest making sure though that by default it builds properly on all supported platforms otherwise it's a step backwards.
Peter
-----owner-openssl-...@openssl.org wrote: -----
To: "Levin, Igor" <ile...@akamai.com>
From: Geoffrey Thorpe
Sent by: owner-openssl-...@openssl.org
Date: 06/11/2014 05:54PM
Cc: "openssl-dev@openssl.org" <openssl-dev@openssl.org>, "Salz, Rich" <rs...@akamai.com>
Subject: Re: Locking inefficiency
From: Geoffrey Thorpe
Sent by: owner-openssl-...@openssl.org
Date: 06/11/2014 05:54PM
Cc: "openssl-dev@openssl.org" <openssl-dev@openssl.org>, "Salz, Rich" <rs...@akamai.com>
Subject: Re: Locking inefficiency
On Tue, Jun 10, 2014 at 3:27 PM, Levin, Igor
<ile...@akamai.com
> wrote:
Geoff,
we did not seem to be able to figure out what openssl Makefile actually builds crypto/threads/th-lock.c
In our particular case we explicitly included that file when building our server, but for “pure” OpenSSL, what make includes th-lock.c ?
Apparently, nothing. I believe the intention is to do precisely what you do. Ie. incorporate that code into your app, so that it registers the pthread locking callbacks through the openssl API.
Cheers,
Geoff
