[1812] in Kerberos_V5_Development
Re: Krb5 Ccache DLL proposal
daemon@ATHENA.MIT.EDU (Theodore Y. Ts'o)
Fri Sep 27 13:38:15 1996
Date: Fri, 27 Sep 1996 13:38:00 -0400
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Ken Raeburn <raeburn@cygnus.com>
Cc: "Theodore Y. Ts'o" <tytso@MIT.EDU>, mikec@geek.grf.ov.com,
harryc@cam.ov.com, pbh@MIT.EDU, krbdev@MIT.EDU, dosdev@MIT.EDU
In-Reply-To: Ken Raeburn's message of 26 Sep 1996 22:06:48 -0400,
<tx1enjo90ef.fsf@cygnus.com>
From: Ken Raeburn <raeburn@cygnus.com>
Date: 26 Sep 1996 22:06:48 -0400
How about a cc_trylock, or cc_lock_with_timeout? I'd like to see
either or both in the UNIX library as well.
cc_trylock seems like a good idea (although it will be useless for us
until we extend the krb5 library API to also support this new
functionality).
As long as it's cheap to determine "is this ccache locked and do I own
the lock". Is the latter part going to be cheap enough on all systems
(assuming we're not talking strictly about Windows, and keeping
multi-threaded applications in mind) that there would be no point in
providing alternate cc_foo_locked versions of the other functions?
There's a simple way to keep it cheap, at least for Unix processes ---
store the thread ID that has the cache locked into the cache handle.
That way, if another thread calls the cache code, the library can
compare the current thread ID with thread ID in the cache handle.
Yes, you'll have to use a thread-specific lock to modify that field in
the cache handle, but you'd need to have that anyway as soon we start
opening the pandora's box of thread support. (Threads and simple just
simply don't belong in the same sentence....)
You do bring up a good point of whether or not we want to provide
thread-specific locking or not. I suppose we really should; can someone
who knows more about Windows thread support comment about what we would
need to do to provide this service?
- Ted
