In-Reply-To: <rt-2856-13034.15.4446916672799@krbdev.mit.edu>
References: <rt-2856-13034.15.4446916672799@krbdev.mit.edu>
MIME-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <DE1BA9FC-592A-11D9-AEFF-000A95909EE2@mit.edu>
Content-Transfer-Encoding: 7bit
Cc: Ken Raeburn <raeburn@mit.edu>, krb5-prs@mit.edu
From: Ken Raeburn <raeburn@MIT.EDU>
Subject: Re: [krbdev.mit.edu #2856] Need a function to clone krb5_context structs for thread safe apps 
Date: Tue, 28 Dec 2004 18:47:43 -0500
To: rt@krbdev.mit.edu
RT-Send-Cc: 
Content-Length: 1230

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