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

[Nicolas Williams]

On Mon, Dec 20, 2004 at 03:31:45PM -0500, Jeffrey Altman wrote:
> 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
> 
> I think you are correct but the problem remains.  gss_...... is a 
> reserved name space and I'm not prepared to polute it.  I wish there
> was a standardized name space allocated for private extensions

And why would "gss_krb5_*" not pollute it either?

>   gss_impl_is_thread_safe()

In my I-D on GSS namespaces I will include directions for an IANA
registry for the GSS namespaces, registration procedures and namespace
allocation policies setting aside portions of some such namespaces for
mechanism-specific extensions and other portions for platform- or
implementation-specific extensions.  Grandfathering of existing
non-standards-track namespace usage could be done, perhaps with such
entries labeled "informational."

Of course, namespace allocation policies require careful thought -- use
of underscores, for example, for indicating that some name is mech-
specific may be a bad idea if there's any languages where there is no
appropriate mapping of the underscores in generic names.

Nico
--