Re: [E-devel] ecore_main_loop_iterate() safety?

[David S. <on...@gm...>]

On Wed, 26 Oct 2011 11:30:26 -0200 Iván Briano (Sachiel)
<sac...@gm...> wrote:

> 2011/10/26 David Seikel <on...@gm...>:
> > On Wed, 26 Oct 2011 09:55:09 -0200 Iván Briano (Sachiel)
> > <sac...@gm...> wrote:
> >
> >> 2011/10/26 David Seikel <on...@gm...>:
> >> > On Wed, 26 Oct 2011 07:01:19 -0400 Mike Blumenkrantz
> >> > <mi...@ze...> wrote:
> >> >
> >> >> On Wed, 26 Oct 2011 20:58:09 +1000
> >> >> David Seikel <on...@gm...> wrote:
> >> >>
> >> >> > On Wed, 26 Oct 2011 06:52:06 -0400 Mike Blumenkrantz
> >> >> > <mi...@ze...> wrote:
> >> >> >
> >> >> > > On Wed, 26 Oct 2011 20:46:44 +1000
> >> >> > > David Seikel <on...@gm...> wrote:
> >> >> > >
> >> >> > > > I'm calling ecore_main_loop_iterate() inside an elementary
> >> >> > > > signal callback.  Is that safe?
> >> >> > > >
> >> >> > > > What's happening is that the signal that is calling
> >> >> > > > ecore_main_loop_iterate() is getting triggered twice, even
> >> >> > > > though it was only sent once.
> >> >> > > >
> >> >> > > > I tried moving the ecore_main_loop_iterate() call to
> >> >> > > > another signal, and THAT signal is NOT triggered twice.
> >> >> > > >  The only difference between the two is that one is
> >> >> > > > triggered by an edje program, the other by a lua script.
> >> >> > > >  When I remove the ecore_main_loop_iterate() call, I
> >> >> > > > don't get the signal triggered twice.
> >> >> > > >
> >> >> > > If you have to call this function, you are doing something
> >> >> > > wrong.
> >> >> >
> >> >> > Then why does it exist?
> >> >> >
> >> >> > The response to that signal takes some time, I want the rest
> >> >> > of the system to keep ticking over during that lengthy
> >> >> > process. This is precisely why such functions exist, no?
> >> >> >
> >> >> No, functions like this exist so that programmers who aren't
> >> >> using events/callbacks properly can hackishly make their code
> >> >> work in ways that it shouldn't.
> >> >>
> >> >> If the response takes time, you should be adding an fd handler
> >> >> or a timer/event to manage it. I can't really give you
> >> >> specifics because I'm lazy and you didn't provide examples.
> >> >
> >> > I really wish I COULD use an fd handler, timer, or event on a
> >> > series of file renames, deletions, and especially syncs.  I
> >> > spent a lot of time trying to figure out how to do it all with
> >> > callbacks, and could not find any such solution.  At least not
> >> > anything would not make the code way harder to understand.
> >> >  Having the code be easy to understand is a strict requirement
> >> > of this project.
> >> >
> >>
> >> Idlers or jobs, or even ecore_thread. The main_loop_iterate()
> >> really exists only because EWL used to have its own main loop on
> >> top of that of Ecore, so on each run of the loop it performed its
> >> own tasks and then called that function to make one iteration of
> >> Ecores main loop. It's still there because... well, because,
> >> but you should not use it.
> >
> > See?  There are other legitimate uses of that function.  If it's
> > broken, and not gonna be fixed, then deprecate it and let's move on.
> > Otherwise, it's entirely possible I just found a bug that needs to
> > be fixed.  Perhaps the bug is in the edje lua signal code?
> >
> 
> No, the way EWL worked, it already processed every signal from Edje,
> returned from all of its callbacks and went back to the main loop. The
> thing was that instead of just using Ecores main loop, it had one of
> its own where it would call that function and then do some other
> things.
> 
> Your problem is that you are going back to the main loop, where it
> will process timers, file handlers, events and whatever else is there
> from an Edje callback. Bad thing. Very Bad Thing. You are basically
> trying to run stuff while Edje is in an inconsistent state.

That should be documented then.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.