issue with krb5_prompter_posix() design
jhutz at cmu.edu
Wed Apr 21 10:38:35 EDT 2010
--On Thursday, April 15, 2010 04:49:30 PM -0500 Nicolas Williams
<Nicolas.Williams at 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.,
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.
More information about the krbdev