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