Back in June, Gerry replied to me privately. Copying his thoughts here, with his permission:
On Sat, Jun 14, 2014 at 8:13 AM, Gerry Calderhead <[email protected]> wrote: > Hi, > > It's been a while since I looked at this - in fact since I originally > reported it. > In the end I concluded it was too much work for me to continue investigating > and re-implemented autogroup using an external perl script > and removed it from my build of openldap. > > My conclusion at the time, IIRC, was that the overlay architecture was a bit > broken and needed a re-think, specifically to avoid the need to be reentrant > - ultimately, by making the overlay CB's asynchronous. > > I think I had in mind something like: > create a thread local holding a notification queue > a _modify() call would add a notification to the queue for each overlay > The stack would unwind to some point (perhaps overlay is wrapped for > this?), and there the CBs would start to happen for overlays > As the overlays do their writes more notifications are added the queue > The cycle repeats until the overlays stop figging with stuff and the > queue empties > > The reason for the thread local was to avoid changing the overlay API > > Even with this approach there is still the possibility to get overlays > caught in an infinite loop - where overlay1 makes a change, > triggers overlay2 which makes a change and triggers overlay1 and so on...
