How is an application supposed to know if a Kerberos library isthread safe?
Sam Hartman
hartmans at MIT.EDU
Mon Dec 20 16:07:28 EST 2004
>>>>> "Jeffrey" == Jeffrey Altman <jaltman at columbia.edu> writes:
Jeffrey> Nicolas Williams wrote:
>> 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
Jeffrey> I think you are correct but the problem remains.
Jeffrey> gss_...... is a reserved name space and I'm not prepared
Jeffrey> to polute it. I wish there was a standardized name space
Jeffrey> allocated for private extensions
I am uncomfortable gating implementation issues on the IETF. I don't
think that the IETF has yet decided to reserve the gss_* namespace.
--Sam
More information about the krbdev
mailing list