krb5 and thread safety, revisited - do we need callbacks?

[Greg Hudson]

> * On such a system, the application should be able to use any one it
> wants.

It's important to recognize that the krb5 libraries aren't necessarily
being used from an application; they may be used from another library
(such as the GSSAPI libraries, but without the kind of tight
integration present between the MIT krb5 and GSSAPI libraries).  It
could even be invoked from multiple different, non-coordinating
libraries (e.g. a SASL library and a library which implements the ssh
protocols).

In cases like that, it's not reasonable to expect the libraries to
pass in locking callbacks, because all hell would break loose if they
disagreed.  Nor is it reasonable for the libraries to pass this
responsibility on to the caller; not only is it a layering violation,
but in some cases (like GSSAPI, again), the library is implementing a
interface which has no provisions for such implementation-specific
constructs.

I'm not really arguing against providing this flexibility if it's
needed (though I have doubts that it really is needed).  But it should
be allowed and encouraged to provide no callbacks, in which case the
system's preferred threading API should be used.  glib does this; if
you really know what you're doing, you can pass in a vtable of
threading APIs, but it's not even documented precisely how you should
do so.

> Larry Greenfield brought up the matter of the GNU Pth library, which
> neither he nor I have first-hand experience with, but which was
> described as a popular cooperative threading library intercepting
> I/O syscalls that may block and switching threads at those points.

As Philip Guenther pointed out in that thread, such a library can't
work robustly unless it also intercepts the native threading
functions, because libc functions like gethostbyname_r() will go ahead
and use the native interfaces.  See
<http://www.imc.org/ietf-sasl/mail-archive/msg01009.html> for details
on what can go wrong.

Unfortunately, in the land of threads, one has to distinguish between
what is done and what is right.  Race conditions don't generally
manifest often enough to climb high on programmers' list of bugs to
fix.  For instance, LDAP is a library which uses the SASL library, but
if you go and read the source code you'll find that it clearly won't
cooperate with an application or another library which also uses the
SASL library.