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!
>> - 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.
You can build ecore api on top of this if you link to the accessor to
the model and every time model change, you fix the accessor to avoid
invalid references.
--
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
