[2133] in Kerberos_V5_Development
Re: krb5 thread safety
daemon@ATHENA.MIT.EDU (Theodore Y. Ts'o)
Fri Dec 20 17:36:26 1996
Date: Fri, 20 Dec 1996 17:36:18 -0500
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Kamen Lozev <lozev+@andrew.cmu.edu>
Cc: krbdev@MIT.EDU
In-Reply-To: Kamen Lozev's message of Fri, 20 Dec 1996 16:40:57 -0500 (EST),
<0mikTd200ioS07PkU0@andrew.cmu.edu>
Date: Fri, 20 Dec 1996 16:40:57 -0500 (EST)
From: Kamen Lozev <lozev+@andrew.cmu.edu>
is the krb5 library thread safe in this release?
if not when do you think it will be?
As long as different threads use their own krb5_context structure and
krb5_auth_context structure (which implies that only one thread can
service a particular connection), the krb5 library is mostly thread
safe.
There are still issues with locking credential caches, if two threads
use the same credential cache. Krb5 uses flock(), and it all depends on
what happens if two threads in the same process use flock() to try to
mediate access to a file. If flock() works on a per-process level, then
you're sunk, and there are problems. If your threading library can
provide per-thread locking with flock(), then you should be OK.
The bottom line is that it's pretty much impossible to make a library as
complex as Kerberos fully thread-safe without writing the library to
work specifically with one threading package. Even if you assume
POSIX.4 threads, you still have to compile the library with a specific
threads library, since some things are done in the threading library's
header files.
Quite frankly, I remain unconvinced of the utility of threads in many
(if not most) applications. The saying of "to someone with a hammer,
everything looks like a nail" really rings true in this instance. I've
seen several instances where adding threads simply made the program
harder to maintain, harder to debug, and added no real value.
- Ted
