krb5 libraries and circular dependencies
Nicolas.Williams at oracle.com
Mon May 31 20:48:35 EDT 2010
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.
More information about the krbdev