threading best practices?

[Chris Hecker]

>> Okay, so if I krb5_get_credentials on the KDC thread, I can then
>> use them in the main thread with a different context...
> Yes, pretty much.

So, I should create the auth_context in the thread that's doing the 
actual communication with each other machine, right?  There seem to be 
some calls to DNS in various functions, so I'm going to need to be 
careful to make sure everything's cached in the KDC thread so nothing 
blocks on the other threads...

I'm building a test program so I can figure out exactly what needs to be 
where for my use-case.

I assume I can have multiple auth_contexts in a single thread, as long 
as I keep straight which one is talking to which other client or server 
and pass them to mk_safe/mk_priv appropriately...

Thanks,
Chris




On 2011/07/22 12:51, Nico Williams wrote:
> On Fri, Jul 22, 2011 at 12:03 AM, Chris Hecker<checker at d6.com>  wrote:
>>> I don't think any u2u stuff is stored in a krb5_context. Can you be
>>> more specific about what you're seeing here?
>>
>> I'm not seeing anything yet, since I'm still trying to figure out how
>> I'm going to do this by playing around with the sample apps.  I think
>> I'm getting confused between krb5_context and krb5_auth_context, I'm not
>> totally clear on how they relate or depend on one another...
>
> krb5_context is just a caller context that must be passed to
> practically all krb5 APIs.
>
> krb5_auth_context is the raw krb5 API equivalent of GSS'
> gss_sec_context_t -- it represents an authenticated channel between
> two end-points.
>
>> Okay, so if I krb5_get_credentials on the KDC thread, I can then use
>> them in the main thread with a different context...
>
> Yes, pretty much.
>
> Nico
> --
>