How is an application supposed to know if a Kerberos library isthread safe?
Nicolas.Williams at sun.com
Mon Dec 20 15:22:13 EST 2004
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
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);
More information about the krbdev