No, multiple independently developed libraries in the same process space
calling the same crypto. code was the problem.
Multiple thread models can't work if they call common code, agreed
there :).
The problem we hit early on was that as a library the only way we could
ensure the stack above us was stable was to use the OS default locking
scheme internally, nothing else would work once the complexity started
climbing. We did it as you suggest, hooked the shared library 'init' entry
points and created the locks when the library was loaded.
Peter
From: Kurt Roeckx <k...@roeckx.be>
To: openssl-dev@openssl.org,
Date: 24/10/2013 06:44
Subject: Re: Self-initialization of locking/threadid callbacks and
auto-detection of features
Sent by: owner-openssl-...@openssl.org
On Wed, Oct 23, 2013 at 12:59:53AM -0500, Nico Williams wrote:
> On Wed, Oct 23, 2013 at 08:32:35AM +1000, Peter Waltenberg wrote:
> > There is no 'safe' way to do this other than hardwired. Admitted, we
have a
> > fairly ugly stack on which to find that out, multiple independently
> > developed lumps of code jammed into the same process, quite a few using
> > dlopen()/dlclose() on other libraries - multiples of them calling the
> > crypto. code.
>
> Oh, good point.
>
> I think what I'll do is add targets that denote "always use the OS
> thread library; disallow setting these callbacks", and a corresponding
> command-line option to ./config. This should be the best option in
> general because of the possibility of the text for callbacks being
> unmapped when the provider gets dlclose()ed.
>
> Then maybe there's no need to bother with the pthread_once()/
> InitOnceExecuteOnce() business. I had assumed, going in, that I needed
> to preserve existing semantics as much as possible, but because that
> might still be the case (even if you're right as to what the ideal
> should be) I will do *both*. (Who knows, maybe there's a program out
> there that insists on using the gnu pth library and not the OS' native
> threading library. Or maybe there's no need to support such oddities.)
You're conserned that you might have 2 libraries in your address
space implementing pthreads? That might of course happen, but
unless they're using symbol versioning it's going to fail. So I
suggest you forget about it and let whoever wants to do that fix
things.
Kurt
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
