issue with krb5_prompter_posix() design

[Jeffrey Hutzelman]

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