thread safety requirements in MIT krb5 libraries

[Ken Raeburn]

Nicolas Williams <Nicolas.Williams at sun.com> writes:
>> 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.

Then, what, the krb5 library grabs the global lock while it
manipulates any ccache, if the ccache support isn't thread-safe,
regardless of whether the ccache in question is used from multiple
threads (since the library can't know that aspect of the application's
behavior)?

Or were you only thinking of OS functions (which was not what I was
getting at in the quoted message)?  The krb5/gssapi library and the
application would each need to grab the lock around such OS calls, but
the application writer would then still have to know which OS calls
they were.  I'm not terribly crazy about this approach.  I'd almost(?)
rather have us just say, "oh, your OS doesn't have thread-safe
versions of X, Y and Z, so the krb5 code isn't quite going to be
thread-safe either, deal with it".  Or, looking at it another way,
declare our code to be thread-safe if it only calls system routines
that are *supposed* to be thread-safe according to whatever relevant
specifications, and let the application writer worry about the OS
failing to meet the specs.

Ken