krb5 libraries and circular dependencies

[Nicolas Williams]

On Mon, May 31, 2010 at 02:18:19PM -0400, Ken Raeburn wrote:
> On May 31, 2010, at 11:51, Nicolas Williams wrote:
> > Does any modern Unix or Unix-like OS supported by MIT use anything other
> > than pthreads now?
> 
> Unless you count Solaris threads or Mach threads, no, I don't think

There's no reason to use Solaris threads instead of pthreads: under the
hood they are the same thing.

I don't know about Mach (or did you mean MacOS?).

> so.  Adding such support as an alternative to pthreads wouldn't be too
> horrific, but adding "figure out which of pthreads or <foo> threads is
> ...

Unless there's a caller context handle then what you propose is
horrific.  We have horror stories around here involving OpenSSL.

> The interesting question is more whether we can stop doing the
> check-if-weak-function-pointer-is-null hack for some UNIX systems, and
> make the calls unconditional on all UNIX systems.

I don't know about Linux or *BSD, but for Solaris you definitely can.

> >> 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.
> 
> In order to conserve pthread TSD key values, which can be in short
> supply in some (maybe not so modern?) implementations, we use one such
> key in the support library, and the Kerberos libraries use an
> enumerator to index into a per-thread array.  So, unless we get rid of
> the indirection (and consume more TSD keys), it's a separate matter
> from the POSIX implementation.

That's only relevant to running out of keys though.

> > 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.
> 
> It's more specific to ELF (and maybe only some ELF platforms?).

Yes, but it can be emulated.

Nico
--