[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/