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

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

Pierangelo Masarati wrote:
On Sat, 2005-12-17 at 03:44 -0800, Howard Chu wrote:

I still prefer this solution:

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

That would be forbidden. I.e., op->o_private can only be valid for as long as op is. (I guess this would be a good time for a C++ style destructor...)

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.

OK. But thread_pool keys aren't really the right place to solve the problem at hand. I.e., threads live longer than operations.
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...

Yeah, that would SEGV... This wasn't a problem in the murky past because any operation could only involve one backend, but obviously things are more complicated now, and a void *o_private just isn't adequate any more.

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