On Mon, Oct 26, 2009 at 1:07 PM, Atton Jonathan <jonathan.at...@gmail.com> wrote: > 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.
Actually, I think we should do this really carefully. I think we should make stringshare thread safe, because their is no way from an user API point of view to use them without messing everything from another thread. So i agree we will need something like 'int eina_thread_safe_init(void)' and 'int eina_thread_safe_shutdown(void)', that track the number of time an user need to be safe and set one global flag that activate some mutex for stringshare. But I don't want to see eina_list or eina_hash, add some pthread lock just because the user can't do it by itself. And in most case, he will be able to do it much more efficiently than we could in 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 :-( The default mempool is thread safe. Definitivly, it should work safely if you build eina with pthread support. If not, it's a bug that should be fixed. For ecore, this is another matter, right now, by design we don't want to >> 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. So maybe when thread safe is required do the same trick for eina_log to. -- Cedric BAIL ------------------------------------------------------------------------------ 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