On Dec 28, 2004, at 07:13, Ezra Peisach via RT wrote:
Show quoted text
> [jaltman@columbia.edu - Mon Dec 27 18:58:59 2004]:
> My original intention with 2855 was to point out a potential race
> condition - and the lack of locking. I do not feel that one needs
> a separate context - unless one wants a different default realm for
> each context... Note however, that krb5_parse_principal uses a static
> default realm (retreived after krb5_get_default_realm) - which would
> make it difficult....
Good point -- and since we're caching the value in the context anyways,
there's no benefit in the one-context case. Might as well drop that
cache.
The restriction of using a krb5_context in only one thread at a time
has been one of the basic assumptions practically since the
thread-safety work was started. If we don't impose that restriction,
then we have to add a mutex to the context, and lock it on basically
every library call (except a few that don't use the context). I think
the list of types we're currently expecting to be
single-thread-at-a-time includes krb5_context, the auth context, the
GSS context, and the simple types like krb5_principal that we're
exposing and can't add a mutex to without changing the ABI.
Ken
RT for krbdev.mit.edu
