[15868] in Kerberos_V5_Development
Re: krb5 libraries and circular dependencies
daemon@ATHENA.MIT.EDU (Nicolas Williams)
Mon May 31 20:49:19 2010
Date: Mon, 31 May 2010 19:48:35 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Ken Raeburn <raeburn@mit.edu>
Message-ID: <20100601004834.GZ9605@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <2F91CBBF-D9D9-4109-B792-8B82B760441F@mit.edu>
Cc: Sam Hartman <hartmans@mit.edu>, "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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
--
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
