krb5 libraries and circular dependencies

[Nicolas Williams]

On Sat, May 29, 2010 at 05:20:07PM -0400, Ken Raeburn wrote:
> On May 28, 2010, at 14:38, Greg Hudson wrote:
> 
> The Kerberos version of the com_err library depends on the support
> library for its conditional thread support, and the libkrb5 objects
> depend on the com_err library.  (I wonder if it's time yet to make the
> "conditional" part just go away, and make the shims map
> unconditionally to pthread calls on POSIX platforms?)  Getting rid of
> this dependency would, theoretically, make it more practical to
> re-merge the divergent flavors of the library.  I wouldn't suggest
> folding the com_err library into the mix.

Does any modern Unix or Unix-like OS supported by MIT use anything other
than pthreads now?

> > A possible concern is a process using Yarrow from both libkrb5 and
> > libkrb5support during the transition period.  For instance, a rebuilt
> > binary might use Yarrow from libkrb5, and also via a non-rebuilt
> > intermediate library (like OpenLDAP or SASL) which uses Yarrow from
> > libk5crypto.  In this case, each Yarrow would be using a separate y_ctx.
> > I don't think this would be a real problem (each PRNG would be seeded by
> > different OS random data), but I'm not 100% certain.
> 
> Cases like this (not Yarrow specifically, but libkrb5 vs libk5crypto
> versions of functions) can also lead to multiple libraries trying to
> register the same thread-specific-data key internally, which IIRC will
> cause an assertion failure.

No, pthread_key_create() doesn't use a string to name TSD -- it uses a
pointer to static storage.  In this case the two instances of the
library would appear to be distinct to the RTLD, so each would have
different addresses for the "same" key.

Loading the same code twice can definitely cause problems.  For example,
if a library uses POSIX file byte range locking, and the two (or more)
instances of the library are accessing and locking the same files, then
expect fireworks.  But I don't think any of that is going on here.

Looking forward to a day when Solaris can do drop-ins instead of merges,
I'd rather see a filter approach, because that's what we do in Solaris
when we fold a library into another.

Nico
--