RE: AttributeDescription caching (was: some problems after your commits)

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: Pierangelo Masarati [mailto: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:

Thanks for reviewing the code, it's always nice to have a second pair
of eyes look it over.

> 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;

The AttributeDescriptions are linked off the individual AttributeType
structures. I doubt that any single AttributeType will ever have more
than a few active AttributeDescriptions. I previously had done exactly
this, but realized I was incurring the overhead of two AVL searches
when only one is needed. (at_find for the AttributeType uses an AVL search.)

> 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.

Yes, I'll change this. I had considered this already, but I vaguely
remembered there was some problem with rdwr locks (way back in the past,
I could not find any references in the archives tho) so I deferred it.

> 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).

I considered this as well, creating the "base" Description at schema
initialization time, but that seemed like wasted effort. The entire
schema will probably contain many unused AttributeTypes that will never
be referenced, and we still have to deal with the unpredictable lang-
variations at runtime.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc