hyc@OpenLDAP.org wrote:
Log Message: Remove redundant search cleanup
Howard,
note that among the issues in slapo-rwm there's the fact that it's attaching a callback structure on the thread's private data instead of malloc'ing (and freeing) it when required. As a consequence, this may prevent slapo-rwm from being called more than once in an operation execution sequence, because it could result in an endless loop or unexpected execution sequences. In fact, when used with a regular database, multiple calls shouldn't occur (one would need to explicitly add more than one instance of slapo-rwm on the same database, which makes little sense). However, gluing more than one database which independently needs slapo-rwm is one such case of multiple calls in one thread execution.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
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 ------------------------------------------
Pierangelo Masarati wrote:
hyc@OpenLDAP.org wrote:
Log Message: Remove redundant search cleanup
Howard,
note that among the issues in slapo-rwm there's the fact that it's attaching a callback structure on the thread's private data instead of malloc'ing (and freeing) it when required. As a consequence, this may prevent slapo-rwm from being called more than once in an operation execution sequence, because it could result in an endless loop or unexpected execution sequences. In fact, when used with a regular database, multiple calls shouldn't occur (one would need to explicitly add more than one instance of slapo-rwm on the same database, which makes little sense). However, gluing more than one database which independently needs slapo-rwm is one such case of multiple calls in one thread execution.
Yes, I saw that. I ignored it because I figured only a single instance of rwm can be active at a time. I guess this isn't quite true; if rwm is configured above the glue overlay, and also configured on individual subordinate databases, there would be a clash. I'll change this to just use a tmpalloc'd callback.
Howard Chu wrote:
Yes, I saw that. I ignored it because I figured only a single instance of rwm can be active at a time. I guess this isn't quite true; if rwm is configured above the glue overlay, and also configured on individual subordinate databases, there would be a clash. I'll change this to just use a tmpalloc'd callback.
That was what my initial idea wanted to avoid, because it seemed to me a waste of resources to malloc something fixed size that needs to be used all times the same, so using the thread keys seemed to me the most obvious solution. Then the multiple instance per thread execution became possible, but I was too lazy to change it. Maybe there's a better approach, but I couldn't figure it out. All in all, malloc'ing a callback is done all times in bind, right now (maybe it could be eliminated there as well... what's more expensive: a thread key lookup or a malloc on the slab?)
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
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 ------------------------------------------
Pierangelo Masarati wrote:
Howard Chu wrote:
Yes, I saw that. I ignored it because I figured only a single instance of rwm can be active at a time. I guess this isn't quite true; if rwm is configured above the glue overlay, and also configured on individual subordinate databases, there would be a clash. I'll change this to just use a tmpalloc'd callback.
That was what my initial idea wanted to avoid, because it seemed to me a waste of resources to malloc something fixed size that needs to be used all times the same, so using the thread keys seemed to me the most obvious solution. Then the multiple instance per thread execution became possible, but I was too lazy to change it. Maybe there's a better approach, but I couldn't figure it out. All in all, malloc'ing a callback is done all times in bind, right now (maybe it could be eliminated there as well... what's more expensive: a thread key lookup or a malloc on the slab?)
A slab malloc is usually faster. It's hard to get meaningful timings for these functions on my system because their average profiled execution time is less than one microsecond, which is the finest resolution my profiler can return. Would have to test on a slower CPU to get more accurate timings...
-
Howard Chu -
Pierangelo Masarati