On Sat, Aug 2, 2008 at 4:49 PM, Gustavo Sverzut Barbieri
<[EMAIL PROTECTED]> wrote:
> On Sat, Aug 2, 2008 at 11:34 AM, Jorge Luis Zapata Muga
> <[EMAIL PROTECTED]> wrote:
>> On Sat, Aug 2, 2008 at 9:27 AM, Gustavo Sverzut Barbieri
>> <[EMAIL PROTECTED]> wrote:
>>> Hi guys,
>>>
>>> I still don't have time to play/help with Eina, but from what I saw so
>>> far, I'd like to propose some ideas and request some features:
>>>
>>> - make data types thread safe. I know evas and other libraries are
>>> not thread safe, but not being able to create lists, arrays and hashes
>>> on different threads is too much limited! I'm not talking about append
>>> to the same list from different threads, but creating nodes for
>>> different lists on different threads. Today this will fail because of
>>> mempool and other cache.
>> I agree with you, making eina thread safe is one of the goals we have.
>> An making the data types thread safe is a must.
>> As a side note, there are already comments on such a thing for
>> eina_error, I'd like to make the error subsystem thread safe, and add
>> a callback to actually do something when an error wants to be printed
>> instead of sending the data to stdout, a callback so a an application
>> might want to write the errors into a file (logging), etc.
> great!
Making eina thread safe is one of the goal. As I care about
performance, I just don't know how, but definitively on the road map.
>>> - provide iterator pattern as a different, complementary system. I'm
>>> using this with Guarana and have iterator for my own list and also
>>> Evas_List. What I have is something as simple as:
>>> eina_iterator_t *eina_XXXX_iterator_get(XXXX_t *object);
>>> int eina_iterator_next(eina_iterator_t *itr, void **data);
>>> void eina_iterator_del(eina_iterator_t *itr);
>>> typedef struct { int (*next)(eina_iterator_t *itr, void
>>> **data); void (*free)(eina_iterator_t *itr) } eina_iterator_t;
>>> users can "extend" from eina_iterator_t and append required
>>> fields, like current list node. This simplifies iteration and
>>> abstracts if you want to use array, lists and even Python/Perl/JS list
>>> objects.
>>
>> Yes, this is good too, im not sure if cedric might want it, as he is
>> some kind of performance addict :) and adding another pointer
>> reference might slow it down, but i prefer this normalization on the
>> API, is a trade-off i prefer.
>
> I don't want everyone to always use it, it can be kept as a helper and
> people who wish to have an abstract data model (usually void *) and
> access it as a list can provide the iterator. I use it in my mvc
> lists, something like: model_set(void *model, eina_iterator_t
> *(*accessor_constructor)(void *model)) and whenever I want to iterate
> the whole list, I delete the old, create a new and start the loop.
>>> - provide accessor (? don't know the real name) pattern, similar to
>>> iterator, this one will access based on index. This one make code
>>> really simple and if you implement it right, for Evas_List you can
>>> have very quick access if you remember last accessed node and search
>>> from head, tail or current position. I also have this code and can
>>> contribute with Evas_List example.
>>>
>>
>> Im not sure if i understood this correctly, but i think what you are
>> proposing is similar to what Ecore_List do, you keep track of the last
>> accessed node on one side and the last added/deleted node in the
>> other, even so IMHO the ecore_list API is not clear enough on what
>> functions update one or the other, and yes, this is possible, i did an
>> ecore_list wrapper using evas_list (i gave the reference for it on
>> another ml thread), and i think is good to have to speed up node
>> retrieve.
>
> It's a bit different as it's an external structure, you can create as
> much iterators or accessors as you want and use them in different
> ways. What you CAN'T is modify the iterated/accessed object while it's
> in use.
>
> Similar to eina_iterator:
>
> typedef struct eina_accessor {
> int (*get)(eina_acessor_t *accessor, int index, void **data);
> void (*free)(eina_accessor_t *accessor);
> } eina_acessor_t;
>
> When you want to create an accessor for Evas_List, you extend this
> with some members:
>
> struct eina_accessor_evas_list {
> eina_accessor_t base;
> const Evas_List *head;
> struct {
> const Evas_List *node;
> int index;
> } last_used;
> }
>
> when you access some index you calculate: am I near to 'index' going
> from head (0), tail (evas_list_count()) or last_used index? Than you
> calculate the direction and how many items you have to go.
This accessor and iterator stuff sounds interresting feature to me
too. I am going to add them to eina during the week. Do people want
this also for inlist too ?
--
Cedric BAIL
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
