[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#5340) REP_ENTRY_MODIFIABLE bug in dynlist
h.b.furuseth@usit.uio.no wrote:
> ando@sys-net.it writes:
>> OK, makes sense. But perhaps creating entries on the stack could be
>> deprecated now that entries are pooled and reused by calling
>> entry_alloc() entry_free(). This is just food for thoughts, we could as
>> well leave all those flags 'round, if we can streamline their handling.
>
> I think we might as well leave them. Since most are for saving memory,
> might even want to expand them eventually. (E.g. separate flags for
> _which_ parts of an entry are modifiable. Modifiable attribute list,
> DNs, values _in_ attribute list, etc.)
>
> For that matter, looking at entry_free/entry_alloc, I don't see how that
> pooling saves more than it costs. It saves 1 malloc for the Entry
> structure, but not the mallocs for the DN and attribute list. And it
> costs two global mutex lock/unlocks per entry, in entry_alloc() and
> entry_free(). An entry on the stack avoids both malloc and locks.
Yes, using the stack is still preferable when it's doable. The point of
entry_alloc() was to avoid heap fragmentation, not to generally save on
mallocs. It might make sense to turn the entry lists into per-thread lists, to
avoid locks in the default cases. But if you follow this path to completion,
that turns into re-implementing tcmalloc ("tc" stands for "thread-caching"
which is exactly what we would be duplicating...). As for the attribute list:
attr_alloc() is also pre-allocated for the same reason.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/