On Fri, Jul 29, 2011 at 5:56 AM, Cedric BAIL <cedric.b...@free.fr> wrote:
> On Fri, Jul 29, 2011 at 3:44 AM, Mike McCormack
> <mj.mccorm...@samsung.com> wrote:
>> On 07/28/2011 10:35 PM, Cedric BAIL wrote:
>>> As I don't want the grumpy guy that don't help. You now have
>>> ecore_main_loop_thread_safe_call that should be the base for your
>>> patch. And I am still not convinced that we need more than that.
>>> People should just use that function when they are doing thread stuff
>>> and we should advertise it in our thread spanking message.
>>
>> OK, thanks for spending the time to write this.
>>
>> If you know you're writing code that's in a thread your function is
>> great. Call it, and then schedule some work in the main loop, it's
>> good.
>>
>> But for a library writer:
>>
>> 1) assume thread safety (1 line):
>>
>> ecore_event_add(LIB_EVENT, e, my_event_free, NULL);
>>
>>
>> 2) Using ecore_main_loop_thread_safe_call (5 lines)
>>
>> static void _event_main_loop_callback(void *data)
>> {
>> ecore_event_add(LIB_EVENT, e, my_event_free, NULL);
>> }
>>
>> /* will always be marshalled through pipe, even when not necessary */
>> ecore_main_loop_thread_safe_call(&_event_main_loop_callback, NULL);
>>
>>
>> 3) Using ecore_main_loop_thread_safe_call, trying to be a bit more
>> efficient (8 lines)
>>
>> static void _event_main_loop_callback(void *data)
>> {
>> ecore_event_add(LIB_EVENT, e, my_event_free, NULL);
>> }
>>
>> if (!ecore_is_main_loop_thread()) /* assuming this function exists */
>> ecore_main_loop_thread_safe_call(&_event_main_loop_callback, NULL);
>> else
>> _event_main_loop_callback();
>>
>> Case 2 & 3 are more verbose, and you need to add such code for *every*
>> call to ecore (in a library).
>
> Case 3, could be easily merged and done directly in
> ecore_main_loop_thread_safe_call. Patch welcome, if I don't get to it
> before anyone.
>
>> So you end up pushing responsibilities to the library writers and
>> applications that are better handled in Ecore itself.
>>
>> IOW, it makes writing ecore code with threads a pain in the butt,
>> and reduces the potential audience of EFL.
>
> Then take that pseudo example :
>
> Eina_Bool _timer_in_main_loop(void *data)
> {
> ....;
> free(data);
> return 0;
> }
>
> void bad_idea()
> {
> tuttut = ecore_timer_add(unlucky, _timer_in_main_loop, something);
> ...;
>
> if (bad_happen)
> {
> ecore_timer_del(tuttut);
> free(something);
> }
> }
>
> 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 ? By trying to say, we are thread safe, you are just hidding more
> and more the issue without solving it. So at the end, app will be less
> stable and more difficult to debug. That's my point. Your patch isn't
> fixing what it is advertising and I think it can't do it by design. C
> is very different from Java, and is very difficult to make it thread
> safe.
> As far as I know, Cocoa, GTK, Qt and Win32 are not thread safe, and
> nobody complain about that. It doesn't prevent anyone from writing
> thousand of greate Cocoa appication (Maybe because they have GCD and
> block and advertise it alot).
I don't know about the others, but at least GTK is kind of thread
safe. You can't ignore that you are using threads and just add
callbacks at will or check for them, but at least you have some ways
to do it:
http://developer.gnome.org/gtk-faq/stable/x481.html
--
Rafael Antognolli
ProFUSION embedded systems
http://profusion.mobi
------------------------------------------------------------------------------
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
