[15684] in Kerberos_V5_Development
Re: issue with krb5_prompter_posix() design
daemon@ATHENA.MIT.EDU (Jeffrey Hutzelman)
Wed Apr 21 10:38:37 2010
Date: Wed, 21 Apr 2010 10:38:35 -0400
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Nicolas Williams <Nicolas.Williams@oracle.com>,
Russ Allbery <rra@stanford.edu>
Message-ID: <14D45DD2176D5BCC7E6646B0@atlantis.pc.cs.cmu.edu>
In-Reply-To: <20100415214929.GY10389@Sun.COM>
MIME-Version: 1.0
Content-Disposition: inline
Cc: MIT Kerberos Dev List <krbdev@mit.edu>, jhutz@cmu.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
--On Thursday, April 15, 2010 04:49:30 PM -0500 Nicolas Williams
<Nicolas.Williams@oracle.com> wrote:
> It's an even worse ("worser") idea to make the choice of allocator
> and/or synchronization primitives a global in the library. OpenSSL, I'm
> looking at _you_.
>
> All library API designers should expect multiple distinct callers in one
> process and aim to have zero global variables/state. Any state that one
> is tempted to think of as global should be encapsulated in a handle
> (such as krb5_context). Look at any major library that you can think
> of, say, NSS, PKCS#11, OpenSSL, libevent -- all of them have got this
> wrong, and some of them have thankfully evolved to address this (e.g.,
> libevent).
All of what you say is true, for allocators and a variety of other cases.
However, synchronization primitives are another beast entirely, because
they generally don't work unless everything in the process agrees on what
threading system is in use. I know that Solaris provides more than one
threads API, but that's not really more than one threading system, because
they're just different interfaces to the same underlying primitives. I
work routinely with software (AFS) that is designed to support a threading
model other than pthreads, and the right thing does _not_ happen if some
libraries decide to use POSIX mutexes anyway.
-- Jeff
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
