[1818] in Kerberos_V5_Development
Re: Krb5 Ccache DLL proposal
daemon@ATHENA.MIT.EDU (Danilo Almeida)
Sun Sep 29 13:02:10 1996
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Cc: Ken Raeburn <raeburn@cygnus.com>, mikec@geek.grf.ov.com, harryc@cam.ov.com,
pbh@MIT.EDU, krbdev@MIT.EDU, dosdev@MIT.EDU
In-Reply-To: Your message of "Fri, 27 Sep 1996 13:38:00 EDT."
<9609271738.AA24262@dcl.MIT.EDU>
Date: Sun, 29 Sep 1996 13:01:02 EDT
From: Danilo Almeida <dalmeida@MIT.EDU>
> 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?
You can do the same thing under Win32.
- Danilo
