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

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



On Fri, 2005-12-16 at 17:36 +0000, ando@sys-net.it wrote:

> I've just fixed it in a rather inelegant manner in HEAD.  Please check
> (the same test I just posted should do the trick).

I'm a bit uncomfortable with this fix (backend.c 1.358), because sooner
or later the same issue could surf again.  I think the o_private
approach may be too error prone, as backends and mostly overlays
proliferate.  It __should__ be strengthened.  One possibility is to
revert to the use of the ldap_pvt_thread_pool_{g,s}etkey() approach;
this may require some changes inside back-bdb for the case at hand, and
it would only solve the issue of separating per-backend private data.
It would not address the specific issue of this ITS, ITS#4184, because
different instances of the same backend are accessing the same type of
private data for the same thread, so we should also provide a mechanism
to augment the key with the database instance; e.g. we should use a
struct berval instead of a pointer as key, and do something like

void *ptr[2];
struct berval key;

key.bv_val = ptr;
key.bv_len = sizeof(ptr);

ptr[0] = unique_key; // identifies the type
ptr[1] = be->be_private; // identifies the instance

and ldap_pvt_thread_pool_{g,s}etkey() should do a
bvmatch() on this key.


Or, we could add a(n optional) 2 level ldap_pvt_thread_pool_{g,s}etkey()
with two keys; for the first one, that identifies the type, the current
container would be accessed, but each entry would actually be another
container that is accessed with the second key, which identifies the
instance.

p.




Ing. Pierangelo Masarati
Responsabile Open Solution

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