krb5 thread support and excess support libraries -- seeking opinions, options

[Ken Raeburn]

On May 6, 2004, at 09:40, Douglas E. Engert wrote:

> Will these routines be useful for other applications that need to
> be thread safe, or are they Kerberos internal only? If com_err
> needs to use them it sounds like they could be independent of
> Kerberos.

They'd be for Kerberos only.  Our com_err code could use them when 
loaded by other applications, but the other applications couldn't use 
them directly.  Or shouldn't, at least.  I'm making Kerberos-aware 
assumptions, like a limit on the number of thread-specific data keys 
that will be determined by how many we use in the Kerberos code.

If any of the people maintaining other forks of the com_err code want 
to use thread-specific data and set up the ability to unload the 
library without storage leaks, they're welcome  to try adopting some of 
this code, or they could implement it other ways (e.g., the Linux ELF 
thread-specific data extensions).  The mutex code should be pretty 
straightforward to reimplement, at least for platforms supporting weak 
references, and it'll probably be slightly more efficient, and arguably 
cleaner, if done in a platform-specific way (i.e., POSIX vs Windows).

Ken