krb5 libraries and circular dependencies

[Ken Raeburn]

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 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 being used and DTRT" probably would be.  I don't think the shim layer should go away altogether, because that's how we switch readily between POSIX and Windows thread calls.  (And potentially some embedded-systems variant too.)

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.

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

> 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?).  Granted, platforms like HPUX and AIX have clearly not gotten as much love from MIT Kerberos in recent years as Linux and Solaris, and I'm not even sure whether they're still using non-ELF formats these days, but if they are, an option like this makes the ports just that much harder (and may mean the users on those platforms just have to suffer with a backwards-incompatible ABI change, bump version numbers independently of MIT, etc).

Ken