Howard Chu wrote:
ELF shared libraries support .init and .fini sections to contain code
that should be executed just after load and just before unload. Assuming
you had a default set of callbacks in the library, it would be simple to
set them here. Likewise any other shared library that manipulates
callbacks can do its own cleanup safely in their own .fini section.
We could be in luck on this point, in that if the dynamic linker already
arbitrates the execution of .init/.fini sections by enforcing a
single-threaded model then the code within the section does not need to
be thread aware.
Now the next issue remains. Adding a new runtime dependency to
libcrypto.so on the platforms native threading implementation.
This is a issue since it is currently clean and some voices want to keep
it so (seemly even for platforms where multi-thread library support is
the norm and the most popular usage pattern on that platform).
It does seem that glibc can keep libpthread out of the mandatory
dependencies, I can only guess this is because it implements system
calls internally that can be built on top of to implement its own
locking requirements. Just the kind of thing it can do but other
libraries don't want to do.
So again back to the packaging idea could a libcrypto_r be created,
which is just a stub DSO.
* It has a mandatory dependency on libcrypto.
* It may have a mandatory dependency on libpthread (or whichever
platform threading library is in use) or it may detect and load at runtime.
* It re-exports all the libcrypto symbols (so the application doesn't
need to link against libcrypto directly at build link time).
* It adds the necessary .init/.fini stuff.
* It can even encapsulates some libcrypto API calls as necessary to
provide a change in policy.
Maybe this is the solution you were alluding to Howard ?
As an aside, it's probably still unsafe to assume any particular thread
model, on any OS. Third party thread libraries are still out there that
run cross-platform (e.g. GNU Pth).
On this kind of subject libcrypto_r would need to provide a documented
way to override the assumed default. However how to do this without
relying on using either of them is another headache. I'm thinking
environment variables, configuration files, file existence tests and
other such ways to configure a DSO at runtime.
This is only an issue if the different threading libraries are used in
incompatible ways and/or if the expected default implementation is not
available on the platform.
For example there can many implementations of spinlocks within a single
application that all co-exist, fewer mutex implementations and fewer
still; ways to manage the creation of threads.
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
