com_err reunification (was: Error while compiling krb 1.5)

[Ken Raeburn]

On Jul 9, 2006, at 16:27, Russ Allbery wrote:
> In theory, it's not entirely thread-safe; if multiple threads load new
> error tables at the same time, bad things could happen.  In  
> practice, we
> decided that this was a sufficiently rare problem that it wasn't worth
> trying to use the MIT Kerberos com_err library and run into all of the
> hideous problems that result from multiple com_err libraries being  
> loaded.

Things could also break if one thread is adding or removing an error  
table while another thread is scanning the list.  (Removing is  
obvious: One thread starts scanning an element in the list, the other  
thread removes it and scribbles over the "next" pointer before the  
first reads it.  The risk in adding to the list becomes clearer when  
you consider the weak memory ordering permitted without locking --  
the reading thread may see an update to the "head" pointer before it  
sees the updates to what has now become the new node in the linked  
list, even if the writing thread did them in the "right" order.)

>> (I don't know if MIT Kerberos bothered to bump the shared version
>> number, but if we are going to do this right, it would be nice to
>> coordinate major version numbers and carefully define what interfaces
>> are guaranteed to exist as of that shared library major version.)
>
> Yeah, this really would be nice.

True.  Though for issues like thread safety, I think it's important  
to consider *not* including the inherently-unsafe interfaces,  
specifically the direct manipulation of the global linked list in the  
generated .c files, so thread safety is *possible* through the  
support library.

Ken