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
