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.