On Fri, 29 Jul 2011, Rafael Antognolli wrote:
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.
gtk is not thread safe. glib is.
Vincent
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
------------------------------------------------------------------------------
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
