threads and contexts and allocations and frees

[Benjamin Kaduk]

On Tue, 16 Apr 2013, Chris Hecker wrote:

>
> As I've discussed here (and on kerberos@) before, I run most of my
> interactions with the KDC in a worker thread so I don't ever block the
> main thread.  Both threads have their own contexts, and I'm careful not
> to access krb5 objects at the same time from two threads.  However, I
> just realized I'm being a little sloppy with some krb5 object
> allocations.  For example, if the creds are cached, I'll call
> krb5_get_credentials on the main thread, with KRB5_GC_CACHED and the
> creds structure.  However, if the creds aren't cached or are invalid,
> I'll call krb5_get_credentials on the worker thread to talk to the KDC,
> and it'll allocate the creds structure and send it back to the main
> thread.  On shutdown, I usually call krb5_free_creds on the main thread,
> regardless of which thread+context was used when allocating the creds.
>
> How bad is this?  I could store the worker thread version of the creds,
> then copy them on the main thread, then delete them back on the worker
> thread, but yuck.  A cursory glance at the code shows it probably
> doesn't matter, but want to be sure.

I believe that with the current implementation, using a different 
krb5_context for freeing a structure than was used to allocate it should 
work just fine.  I don't think we make a guarantee anywhere that this will 
always work, though (but it seems unlikely that we would break this 
ability).

-Ben Kaduk