mit krb5 and threads - api

[Jeffrey Altman]

Ken Raeburn wrote:

>As for the internal shim layer interface, I'm thinking about this so
>far, based loosely on the pthread API:
>
>   #include "k5-thread.h" /* not installed */
>
>   k5_mutex_t foo_mutex = K5_MUTEX_INITIALIZER;
>   int k5_mutex_init(k5_mutex_t *);
>   int k5_mutex_destroy(k5_mutex_t *);  /* void? */
>   int k5_mutex_lock(k5_mutex_t *);
>   int k5_mutex_unlock(k5_mutex_t *);   /* void? */
>
>   k5_key_t key;
>   int k5_key_create(k5_key_t *, void (*destructor)(void *));
>      /* or maybe a fixed number of predefined key values? */
>   void *k5_getspecific(k5_key_t);
>   int k5_setspecific(k5_key_t, const void *);
>   ... something to call at library termination ...
>
>Mutexes would be simple -- a thread isn't allowed to lock a mutex it
>already has locked.
>
Is there a reason we are making this requirement?

Are we planning on implementing our own mutexes? 

If so, will these mutexes be global to the system or
to the local process?

OpenAFS has run into some problems because developers
make the assumption that mutexes can be safe locked
twice within the same thread.  This has lead to some
interesting deadlock situations which are difficult
to debug.