[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] Ecore_List bugs


On 7/30/06, Simon TRENY <simon.treny@free.fr> wrote:
Hi there,

I notice some "bugs" (or strange behaviour) in the calling policy of
the free-callback in Ecore_List:

Strange behavior maybe (depending on your perspective), but the listed
behavior below is how they are intended to work.

- If you call ecore_list_destroy(), the free-callback will indeed be
called on all the elements.
- If you call ecore_list_clear(), the free_cb won't be called.

This API distinction was made so that you could have a list with a
free callback, but still have a way to remove all items from the list
without freeing them. For a somewhat artificial example, say you have
a queue of file descriptors that you copy to an fd set for use with
select or poll. The list keeps a reference until all the descriptors
are copied successfully, then clears them out until they get
re-submitted. You may also want to be able to have a free callback
that will close all the fd's when you destroy the list.

While the example may not be common place, I have hit a couple of
circumstances where I've needed the capability to clear out the list
without calling the free callback.

- ecore_list_remove() doesn't call the free_cb neither. Ok, there is
ecore_list_remove_destroy(), but I just find it really confusing. When
you set a free_cb, you usually want it to be called when you remove an

All of the ecore_list_remove functions return the value that was
removed from the list. This is so you can easily use it as a stack or
queue. From an API consistency standpoint, it didn't make sense to
have the remove functions perform differently depending on whether
there was a free callback assigned, and the pointer would most likely
be invalid after the free callback was triggered.

Another thing, why is there a distinction between Ecore_List and
Ecore_DList? It is just to save a pointer per node in the memory?
Because, I don't think it is worth it, and it's just confusing imho.

While the space savings are negligible (non-existent due to allocation
alignment in most cases), it just distinguishes between a singly and
doubly linked list. I don't see a disadvantage of supplying both data
structures and the programmer should know which one fits their
circumstances. Also, with the abstracted API and the fact that
internal node pointers aren't exposed, we could add defragmenting
capabilities to the list code to group allocations of nodes and
actually gain memory savings from that missing pointer. If the memory
fragmentation can be reduced, then 4 to 8 bytes per list entry seems
worthwhile to me when dealing with large lists. This may be able to be
improved even more by grouping value pointers without a full node.