thread safety requirements in MIT krb5 libraries

[Nathan J. Williams]

<raeburn at MIT.EDU> (Ken Raeburn) writes:

(jumping in with a few points about threading libraries, since I've
been up to my eyeballs in them for a while)

> It would be nice if we could avoid having to link against the system
> pthread library, when it is a separate library, if the program isn't
> going to create threads.  Many systems have support for weak
> references (where &foo is a null pointer rather than a link-time error
> if foo isn't linked in), which would let us make the pthread library
> optional. If that doesn't work on some system, however, I don't think
> it's a disaster if we start requiring the pthread library.

You want to use the weak-reference support where possible. See
below...

> Dynamic loading:
> 
> I believe it's going to be a requirement that we be able to load the
> Kerberos or GSSAPI library dynamically, do some stuff with it, and
> unload it, and repeat the cycle, without resource leaks, at least for
> a properly written program.

This introduces some difficulties if the libraries have recorded
dependencies on the pthread library, because dynamically loading the
pthread library is not widely supported - in fact, it's thought to be
an atrociously bad idea. It tends to muck up the weak-linkage you
mentioned before; you get a dummy version of pthread_mutex_lock() but
the real version of pthread_mutex_unlock or something similarly
bad. Thus, if your library is going to be dynamically loaded, it needs
to just use whatever thread bindings are already present in the
executable.


>  So any thread-specific storage or globally-used heap storage we
> keep but hide from the application needs to be freed up when the
> library is unloaded.  That shouldn't be hard, but the internal APIs
> we use for per-thread storage might need a little adjusting from the
> POSIX versions to support this better.

Another followup mentions that there's a limit on TSD keys; SUSv3
mandates a minimum maximum of 128 keys. Additionally, the
pthread_key_delete() function is broken-as-designed and can not be
relied upon not to leak memory.

> It would probably be difficult, if not impossible, to make the library
> code be async cancel safe.  However, making it safe for synchronous
> cancellation may be doable.  How much do threaded programs actually
> use pthread_cancel or the Windows equivalent?

You don't care about making exposed library routines async-cancel
safe, you only care about deferred-cancel safety. Async-cancel safety
is pretty much only good for compute-bound threads with state that can
be entirely destroyed at will. The only system or library calls
guaranteed to be async-cancel safe are pthread_setcancel{type,state}()
and pthread_cancel(). Nobody should even be thinking about calling a
krb routine inside async-cancellable code.

        - Nathan