Re: Dynamic Linker feature set query

[Petr Baudis <pasky at suse dot cz>]

  Hi!

On Tue, Jun 29, 2010 at 09:52:05AM +0100, Darryl L. Miles wrote:
> The OpenSSL library supports a very wide variety of platforms that
> it can be built to run on, from tiny embedded devices to huge
> non-uniform systems, it also support multithreading.  Due to the
> wide variety of platforms (which is a major project goal) it doesn't
> tie itself to any particular platform or threading model.  This
> means that every multithreaded user must initialize themselves the
> threading model callbacks before the rest of the library can be
> consider thread-safe (in respect of the libraries own set of
> multithreaded rules).
> 
> I use the term "superior executable" to mean to executable that owns
> the process and OpenSSL is more often known as a pair of libraries
> libcrypto.so and libssl.so.
> 
> This presents a major problem with GNU based systems in that it is
> possible a "superior executable" doesn't link or use OpenSSL
> directly itself, but two or more modules which are loaded via
> dynamic linking do.  When those two modules are built they have a
> dependency on OpenSSL, I shall refer to these modules as
> "another.so" and "yetanother.so".
> 
> Therefore when the "superior executable" loads "another.so" this
> implicitly drags in "libcrypto.so" now because the process is
> multithreaded the initialization code of "another.so" ultimately
> configures up the threading model callbacks before it proceeds to
> use "libcrypto.so".
> 
> The "superior executable" due to its modular design then calls to
> load "yetanother.so" this also implicitly drags in "libcrypto.so"
> now because the process is multithreaded the initialization code of
> "yetanother.so" ultimately configures up the threading model
> callbacks before it proceeds to use "libcrypto.so".

  We managed to clarify this after a long IRC discussion. The problem is
that two .so modules can be dlopen()ed in parallel, and each of them may
in turn pull in libcrypto.so and call a setup function to set up the
"threading model". What the OpenSSL guys ask is a facility in the
dynamic linker to serialize these setup calls.

  Their motivation is that they do not want to unconditionally depend on
libpthread for single-thread applications, and they also do not want to
depend on libpthread API in particular and instead allow "threading
model" choice within the setup call - therefore, the setup call itself
cannot do a proper lock before the threading model is set up.


  I do not think this is a sane request. The OpenSSL guys want to keep
their "generic threading model" same across all the systems and would
prefer the platform to adapt to their requirements rather than them
adapt to the requirements of the platform. I think this is bad attitude,
and have two main issues:

  (i) The OpenSSL pushes the genericity of their threading model to run
time and would like the dynamic linker to do the work. But this makes no
sense on GNU/Linux where the only concievable threading model is
pthreads. The genericity should be at the compile time here.

  (ii) No cooperation from the dynamic linker is neccessary, you can do
all serialization from within the library easily.

  Also, there is plenty of available workarounds if the OpenSSL guys do
not want to clean up their model - e.g. you can trivially use atomic
instructions to ensure only one of the threads will do the setup.

-- 
				Petr "Pasky" Baudis
The true meaning of life is to plant a tree under whose shade
you will never sit.