Dynamic Linker feature set query

[Darryl Miles]

Mike Frysinger wrote:
> On Tuesday, June 29, 2010 08:10:36 Petr Baudis wrote:
> glibc already provides support for this exact scenario.  many of the main
> libpthread functions are merely stubs in the C library that return appropriate
> success values when libpthread is not loaded.  if an app does link against
> libpthread, then the real pthread functions are called transparently.
>
> i.e. on glibc systems, you may always utilize pthread mutex functions in
> shared libraries without needing to link against libpthread yourself and
> things will "just work".

Okay to understand this better.

In glibc enviroments where libpthread is not loaded (or not supplied by 
the platform) there are still available symbols for pthread mutex 
functions but calling them is a no-op ?

Are there any issues with the point in time when libpthread maybe loaded 
versus the point in time when OpenSSL maybe loaded ?  How does this 
interaction play out, there is an implicit notation that libpthread is 
not being used by libc so it not loaded already at the start of these 
interactions.  It also needs to be taken into account that OpenSSL maybe 
loaded more than once by independent user unaware of each other.

I think you are still under the thought that OpenSSL will use no-op 
pthread mutexes by default, this is not how it has ever worked.  This 
could however be considered under a new DSO soname, such as 
libcrypto_r.so and libssl_r.so.


> agreed.  openssl's configure system is already a huge pile of crap with
> system-specific checks sprinkled all over.  simply add one more for glibc
> compatible targets and use the native threading library.

OpenSSL doesn't require to use threading itself, since by default it is 
a single-threaded library.  This means it doesn't link with libpthread 
directly (which would make it a mandatory runtime requirement to use 
OpenSSL).

However if the application program using OpenSSL requires to use 
multi-threading and wants to make certain API calls into OpenSSL 
concurrently then it can configure OpenSSL at runtime to achieve this.

This is a runtime configuration choice of their use of OpenSSL.

A large portion of OpenSSL API is not affected one way or the other by 
threading.  So different independent users within the same process may 
or may not have the need to configure up threading at all.  It is the 
arbitration of the first user to do so (migrate from single to multi) 
that is the focal point of the problem.



I can certainly see there is a lack of any API or mechanism by the GNU 
dynamic linker to help arbitrate concerns over DSO load/unload 
operations and before-first-use and after-last-use DSO 
initialization/shutdown operations.

It seems the dynamic linker itself already has taken the necessary steps 
internally to protect itself (from concurrency issues) but failed to 
understand that it maybe charged with the task of loading/unloading 
single-threaded DSOs into a multi-threaded environment.  This is not a 
problem presented in a static linked environment but one created by the 
advent of dynamic linking in the way GNU does it (other platforms have 
workable solutions, that would not require mutating the library build to 
provide a new DSO soname).



Also to add: my previous example of some kind of dlopen() flag would not 
address all issues, but it would address concurrency issues relating to 
before-first-use and after-last-use.  I think also DL API to ask the 
handle for its reference count would be needed as well. A well designed 
_DllMain would be better however, easier for users of DSOs to manage.



Thanks for your replies so far.  This exercise is more of clarification 
of what stuff exists outside of the OpenSSL project that may assist with 
the problem and the general view point of the GNU runtime system 
maintainers.

Darryl