On Mon, Aug 1, 2011 at 4:33 AM, Mike McCormack <mj.mccorm...@samsung.com> wrote:
> On 07/29/2011 05:56 PM, Cedric BAIL wrote:
>> Then take that pseudo example :
>>
>> Eina_Bool _timer_in_main_loop(void *data)
>> {
>>    ....;
>     lock_data_mutex();
>     if (!data_was_deleted)
>       {
>>        free(data);
>       }
>     data_was_deleted = Eina_True;
>     unlock_data_mutex();
>>    return 0;
>> }
>>
>> void bad_idea()
>> {
>>    tuttut = ecore_timer_add(unlucky, _timer_in_main_loop, something);
>>    ...;
>>
>>    if (bad_happen)
>>       {
>          lock_data_mutex();
>          if (!data_was_deleted)
>            {
>>             ecore_timer_del(tuttut);
>>             free(something);
>            }
>          data_was_deleted = Eina_True;
>          unlock_data_mutex();
>>       }
>> }
>>
>> This code will work just fine in the main loop. Now in a thread it's
>> full of race condition and double free. Tell me how you can make it
>> work ?
>
> Add a mutex. See above.
>
> Nobody said threaded programming is easy.  I'm just adding one tool.
> Maybe you don't want to use this tool, that's OK.  Maybe you want to
> provide a different way to do it, that's OK too.  Maybe you want to
> make a law against using threads with ecore in EFL code, that's OK too.
> Saying the tool itself is bad is a non-started, IMO.
>
> The fact is, people already write this kind of racy code.  They think
> it works, and when it crashes in ecore, EFL gets the blame.
>
> So you can stand stubbornly refuse to fix it, or move the problem to
> their code, so it will crash outside of ecore, and people will not
> blame EFL.

That's were we really disagree I think. I really think that you can't
protect the EFL yet against this kind of race condition and be sure
that the issue will show up in the backtrace of their app and not in
EFL. I really know and understand why you want to do that. I really
think that telling people that don't understand thread to not use them
or direct them to use the right function to make the call in the main
loop would be the only solution to reduce the burden put on you. But
if you really think that by making it thread safe, you will have less
false positive bug report, then fine. Use the function I added to
ecore.c to do your patch, and you should put some effort on my
prototype of Eina_Object as I think it will help to solve some race
condition to.

> Additionally, people who grok threads well (admittedly not many)
> can write code that works with ecore main loop.

They already can.

> Support choice, and suggest the best way.

As I say from the beginning, I am really not for that stuff in EFL,
but if you do it fine, I will not oppose it.
-- 
Cedric BAIL

------------------------------------------------------------------------------
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to