Re: long running threads (was ITS#3404)

["Jong-Hyuk" <jongchoi@watson.ibm.com>]

> Actually the syncrepl provider does not occupy any thread for a long
> period of time. The biggest problem was its use of sl_realloc in
> building syncUUID sets for some large number of UUIDs, which overran the
> thread-specific malloc pool for a particular thread due to this bug. But

Yes, the realloc error was hit not because it's long running but because of
the use of ber_bvarray_add_x() to add more set elements.
BTW, from the thread local memory's viewpoint, the original syncrepl
provider extends the lifetime of its slab for persistent operation by
detaching the memory context from the thread context. I took this path
because of the potential need for the continued use of allocated objects
across multiple invocations of a persistent search while at the same time
benefiting from the sl_malloc() interface. Hence, we can say that the
syncrepl provider does continue to occupy the memory context although its
execution spans over multiple threads.

> restructuring that code to allocate a single re-usable buffer instead of
> reallocing/freeing it over and over avoids the issue. Even without the
> stack-based sl_malloc design constraints, it's always better to allocate
> a buffer once rather than realloc/free it repeatedly.

Although it might be suboptimal to performance, it should not affect its
validity.

> Likewise the syncrepl consumer isn't really a long running thread; it
> always gets a completely reset slab when it gets control. Of course,
> when it receives a lot of updates its individual operations aren't
> getting a fresh slab as normal operations would. In this case just
> wrapping the syncrepl operations in sl_mark/sl_release to reset the slab
> for each operation would avoid most problems there. We removed the
> mark/release functions a long time ago, but I think there are still
> situations (like the consumer) where they're useful.

Instead of continuing to use the stack-based allocator, we should consider
moving to the heap-based one at least for long running tasks.

- Jong-Hyuk