thread safety requirements in MIT krb5 libraries

[Nicolas Williams]

On Fri, Dec 19, 2003 at 06:07:48PM -0500, Ken Raeburn wrote:
> Jeffrey Hutzelman <jhutz at cmu.edu> writes:
> >> Should we provide a way to describe which objects can be used
> >> simultaneously from multiple threads and which cannot, in case we add
> >> mutex protection to additional objects in the future?
> >
> > No.  Document the API, and leave it at that.  Runtime checks add a
> > level of complexity both for Kerberos and the application, and I don't
> > think they'll be heavily used.
> 
> Actually, I was thinking of compile-time checks:
> 
>   #ifndef KRB5_THREADSAFE_CCACHE
>       if (pthread_mutex_lock(&global_ccache_lock) != 0) { ... }
>       err = krb5_do_something(my_ctx, global_ccache);
>       pthread_mutex_unlock(&global_ccache_lock);
>   #else
>       err = krb5_do_something(my_ctx, global_ccache);
>   #endif
> 
> We can document what a given version does, but if the next version
> changes things, then what?

How about letting the app pass in a pointer to a global lock.  If none
is passed in the a lock global to krb5 is used.  And the code in krb5
around OS functions that are MT-unsafe uses the global lock -- the one
provided by the app or, if the app did not privde one, the global krb5
lock.

Nico
--