actually all eina should be thread safe. Maybe eet and ecore too. If you are not against this I will start to work on eina.
2009/10/25 Gustavo Sverzut Barbieri <barbi...@profusion.mobi> > On Sun, Oct 25, 2009 at 5:20 PM, Atton Jonathan > <jonathan.at...@gmail.com> wrote: > > hey, > > > > I talked a week ago with cedric about making eina stringshare thread > safe. > > > > The mutex could be activated/deactivated with a classic function and then > 2 > > macros will be use: > > > > LOCK : if(mutex_activated) pthread_mutex_lock() > > UNLOCK : if(mutex_activated) pthread_mutex_unlock() > > > > By default the mutex can be deactivated and the developer activate it if > > necessary. > > > > What do you think about this idea ? > > The only problem with this is inconsistency. Okay, we have stringshare > as this, but still default mempool is not so you cannot allocate list > nodes... then you cannot add ecore idlers/timers/pollers/... from > threads, and so on. Inconsistency is bad :-( > > I really don't see any clear solution to this problem. Maybe we could > have something like glib's "threads init". I have this for logging, > but i was really reluctant to add it. But if so, then we must make > sure all types would be thread safe. > > BR, > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN: barbi...@gmail.com > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > -- Regards. ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
