On Dec 28, 2004, at 07:13, Ezra Peisach via RT wrote:
> [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