On Wed, 26 Oct 2011 11:30:26 -0200 Iván Briano (Sachiel) <sachi...@gmail.com> wrote:
> 2011/10/26 David Seikel <onef...@gmail.com>: > > On Wed, 26 Oct 2011 09:55:09 -0200 Iván Briano (Sachiel) > > <sachi...@gmail.com> wrote: > > > >> 2011/10/26 David Seikel <onef...@gmail.com>: > >> > On Wed, 26 Oct 2011 07:01:19 -0400 Mike Blumenkrantz > >> > <m...@zentific.com> wrote: > >> > > >> >> On Wed, 26 Oct 2011 20:58:09 +1000 > >> >> David Seikel <onef...@gmail.com> wrote: > >> >> > >> >> > On Wed, 26 Oct 2011 06:52:06 -0400 Mike Blumenkrantz > >> >> > <m...@zentific.com> wrote: > >> >> > > >> >> > > On Wed, 26 Oct 2011 20:46:44 +1000 > >> >> > > David Seikel <onef...@gmail.com> 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.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
