AttributeDescription caching (was: some problems after your commits)

[Pierangelo Masarati <masarati@aero.polimi.it>]

Howard,

I'm redirecting this thread to -devel because it might be of interest

> Heh. I've also been working too late into the night.  }-)
> The entry_encode/entry_decode changes are still only used by back-bdb.
> But the AttributeDescription stuff should be noticable everywhere.

I have a couple of notes:

first, as the number of AttributeDescription is large and will grow
even larger, maybe a better storage than a linked list could be used;
for code reuse, an AVL tree would be a nice solution;

second, in slap_bv2ad there's a problem in that you go thru the
list with no read lock in place; this means some other thread might 
change the list while you're going thru it. This should be considered
non-reentrant. A rdwr lock read-locked at the beginning should also 
allow to get rid of the cross-check you do to ensure no other thread
inserted the AttributeDescription.

Maybe we can get rid of these controls by simply creating the cache once 
when the schema is read from the configure file (and accounting for cache
update as soon as dynamic schema update is implemented, if need be).

Pierangelo.