threading best practices?

[Chris Hecker]

Hi, my kerberos application is threaded, so all the lowlevel 
communication between the clients and the servers is happening on 
separate threads that queue messages to the main thread.  I'm going to 
integrate kerberos authentication to all this, and I'm trying to figure 
out the best way to do this.

This link talks about some of the caveats, like not sharing contexts 
across threads:

http://mailman.mit.edu/pipermail/krbdev/2009-March/007571.html

Since krb5 talks to the KDC on blocking sockets, what I'd like to do is 
have all communication with the KDC on its own dedicated thread so it 
never blocks my app (a video game).  But, the link above says not to 
share contexts between threads, so I'm not exactly sure how to 
accomplish this.  Should I have a context in the KDC thread, and then 
store the tickets in the ccache, and then load them in the main thread 
(knowing they won't hit the net because they're already loaded?). 
Should I have a single context and then use a mutex to share it between 
threads, so if the KDC thread is active, then the main thread can't 
authn anything until it's done?

I need to do normal client<->server authn and also client<->client 
authn, which I'm going to do with the user-to-user stuff, so I'll need 
to talk to the KDC multiple times per session.  It seems like the u2u 
stuff is stored in the context, so I'm not sure how to make all this work.

I'd also like to guarantee nobody in krb5 will try to use a socket 
without me specifically asking them to, so is there a list of APIs that 
talk to the net?  An example is some APIs have a flag that tells them to 
fail with an error code instead of contact the KDC, which is what I 
want.  Can anybody think of APIs I need to watch out for here?

Once things are established with mutual authn & subkeys, the main thread 
is just going to use mk_safe and mk_priv, basically.

Thanks,
Chris