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.

>
>  - 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.

>
>  - 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.

>
> --
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --------------------------------------
> MSN: [EMAIL PROTECTED]
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
>
> -------------------------------------------------------------------------
> 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
>

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

Reply via email to