On Sat, 2005-12-17 at 03:44 -0800, Howard Chu wrote:
I still prefer this solution:
http://www.openldap.org/lists/openldap-devel/200510/msg00063.html
I missed that post. However, this would not work in all those cases we
use a temporary Operation, so that stacking occurs on the temporary, and
data stacked on o_private is supposed to live longer than the temporary
(if there's any place where this occurs).
As for two-level thread_pool keys, the approach I used previously in back-bdb was to use the be_private pointer as a key, and to use (pointer+1), (pointer+2) etc. for other keys related to the same backend.
In principle this does not guarantee that keys are unique the more keys
a backend uses; I understand a collision is very unlikely. However, I
think it delegates too much responsibility on the single backend/module,
while I'd prefer an approach that unifies the handling of key uniqueness
and storage details under a well-defined API, since more modules would
share the same mechanism.
In any case, I believe we need to fix this somehow, as the need for persistent private data passed across calls will grow in the future, and we need to ensure as much as possible that collisions do not occur when we couple modules in fancy manners.
For example, currently back-meta casts to o_private = (void *)tnum the
number of the target that's performing an operation. I wonder what
would have happened happen if ACL checking occurred using a group that's
stored in back-bdb...
-- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/