Re: [E-devel] eina stringshare thread safe

[Atton J. <jon...@gm...>]

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
others.
2 macros has been updated to add the possibility to unlock a mutex if
necessary.
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 <ced...@fr...>

> On Mon, Oct 26, 2009 at 1:07 PM, Atton Jonathan
> <jon...@gm...> 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 <bar...@pr...>
> >> On Sun, Oct 25, 2009 at 5:20 PM, Atton Jonathan
> >> <jon...@gm...> 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
>



-- 
Regards.