A new version of the patch wit eina_threads_init() and
eina_threads_shutdown(). maybe we can add a call to these functions in
ecore_thread_run () ?
2009/10/28 Atton Jonathan <jonathan.atton@...>
> I have attached the patch.
> With the help of Cedric I have made this patch.
> 2 mutexs are used, one for the strings with a size < 4 and one for the
> 2 macros has been updated to add the possibility to unlock a mutex if
> In this version the mutexs are activated if eina is installed with the
> pthread support ( I use the same code than eina_log ). If you wish I can add
> a function to manually active the mutexs.
> The patch is simple, this was not a big job to do. Helgrind reports no
> errors with my application and I use a lot of eina stringshare + threads
> (without the patch my application segv after eina reports some invalids use
> of eina stringshare). Of course I do not use all the combinations of calls.
> E17 works too.
> 2009/10/26 Cedric BAIL <cedric.bail@...>
> On Mon, Oct 26, 2009 at 1:07 PM, Atton Jonathan
>> <jonathan.atton@...> wrote:
>> > actually all eina should be thread safe. Maybe eet and ecore too. If you
>> > 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 <barbieri@...>
>> >> On Sun, Oct 25, 2009 at 5:20 PM, Atton Jonathan
>> >> <jonathan.atton@...> 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
>> >> 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
>> >> > 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