[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: o_private (Was: (ITS#4184) Lockup when moding one particular entry)

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


Ing. Pierangelo Masarati
Responsabile Open Solution

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
Office:   +39.02.23998309          
Mobile:   +39.333.4963172
Email:    pierangelo.masarati@sys-net.it