thread safety requirements in MIT krb5 libraries

[Nicolas Williams]

On Mon, Dec 22, 2003 at 03:25:30PM -0500, Ken Raeburn wrote:
> Nicolas Williams <Nicolas.Williams at sun.com> writes:
> >> Actually, I was thinking of compile-time checks:
> >> 
> >>   #ifndef KRB5_THREADSAFE_CCACHE
> >>       if (pthread_mutex_lock(&global_ccache_lock) != 0) { ... }
> >>       err = krb5_do_something(my_ctx, global_ccache);
> >>       pthread_mutex_unlock(&global_ccache_lock);
> >>   #else
> >>       err = krb5_do_something(my_ctx, global_ccache);
> >>   #endif
> >> 
> >> We can document what a given version does, but if the next version
> >> changes things, then what?
> >
> > How about letting the app pass in a pointer to a global lock.  If none
> > is passed in the a lock global to krb5 is used.  And the code in krb5
> > around OS functions that are MT-unsafe uses the global lock -- the one
> > provided by the app or, if the app did not privde one, the global krb5
> > lock.
> 
> Then, what, the krb5 library grabs the global lock while it
> manipulates any ccache, if the ccache support isn't thread-safe,
> regardless of whether the ccache in question is used from multiple
> threads (since the library can't know that aspect of the application's
> behavior)?

No.

> Or were you only thinking of OS functions (which was not what I was
> getting at in the quoted message)?  The krb5/gssapi library and the
> application would each need to grab the lock around such OS calls, but
> the application writer would then still have to know which OS calls
> they were.

Yes.

>             I'm not terribly crazy about this approach.  I'd almost(?)
> rather have us just say, "oh, your OS doesn't have thread-safe
> versions of X, Y and Z, so the krb5 code isn't quite going to be
> thread-safe either, deal with it".  Or, looking at it another way,
> declare our code to be thread-safe if it only calls system routines
> that are *supposed* to be thread-safe according to whatever relevant
> specifications, and let the application writer worry about the OS
> failing to meet the specs.

I have no problem with this, but you had concerns about how portable
app code would deal with this and I offered one solution that makes it
easier on the portable apps developer.

Now, I don't have this problem, so I don't much care :)

Cheers,

Nico
--