This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Dynamic Linker feature set query


On Wednesday, June 30, 2010 07:09:59 Darryl Miles wrote:
> 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 ?

glibc cannot be built without pthread support.  but ignoring that, the other 
statement is correct.

> 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.

while it may be possible to construct that scenario (main application does not 
link against libpthread, but some library it links and/or loads is linked 
against libpthread), imo it's an invalid scenario and that other library is 
broken.

> 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.


i really have no idea how openssl handles threading.  just basing info on what 
i think you'r saying.

> 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).

it is not the ldso's job to fix broken DSOs.  glibc already provides a trivial 
way (pthread stubs in the C library) for DSOs to always work regardless of 
threading state.
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]