How is an application supposed to know if a Kerberos library isthread safe?

[Nicolas Williams]

On Mon, Dec 20, 2004 at 02:35:43PM -0500, Ken Raeburn wrote:
> Does a "true" indication (I assume non-zero means true) mean "this 
> library is using mutexes where needed", or does it mean "this library 
> has thread-safety support, which on some systems means it'll use 
> mutexes only if your application has pulled in the system thread 
> support"?  I.e., for the 1.4 libraries built with thread support and 
> linked into a non-threaded application, should these functions return 
> true or false?  (Not that it would matter much for a non-threaded 
> application, but it would clarify the specification a little; the 
> latter is easier to implement, too.)
> 
> From the "boolean" return value I assume it's just true/false, not some 
> sort of versioning, i.e., in case we change things in the future and 
> make more objects incorporate mutexes that we assume for now just won't 
> be shared, we'll have no way to indicate it....

So the question is whether the darned thing is MT-safe; MT-hot is
another issue and I'm not sure that that needs to be indicated.

Also, one would think that the entire GSS mechglue and all its mechs
should be MT-safe -- if one mech isn't and the GSS mechglue doesn't work
around that, then none of them are (think of concurrent calls to
GSS_Acquire_cred() with GSS_C_NULL_OID_SET for desired_mechs).  The
mechglue, after all, could maintain a global mutex for dealing with
MT-unsafe mechs.

So, the right function prototype perhaps shouldn't have anything in it
that is mechanism-specific -- not in the function name nor any
parameters (as in my suggestion).

OM_uint32 gss_is_thread_safe(OM_uint32 *minor_status, OM_uint32 *mt_safe);

Cheers,

Nico
--