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. > In a later project I'll be converting an existing large program over to > be using EFL. It has it's own main loop, so I'll likely need to do > exactly what EWL did. Eventually I'll want to get rid of its main loop > and use the Ecore one, but until then, it would be useful to have this > function as a crutch. Would be even more useful if it worked with lua > signals. > > Idlers and jobs just make the code less readable, having to break up > things into a whole bunch of one liners, then pulling them together > elsewhere. I did that for the printer code, I was hoping I could avoid > it for this part. A thread is just gonna lead to nasty syncronisation > problems, and make this part of the code a whole lot less robust. > Considering this part of the code only exists to make things more > robust... seems rather silly. > > Sometimes you can't make your coding problem fit into the nice neat > boxes your chosen toolkit provides. > > In the mean time, let's just see if there might be a bug somewhere in > EFL, perhaps someone might have some insight into that. Which was the > point of this thread. > > -- > A big old stinking pile of genius that no one wants > coz there are too many silver coated monkeys in the world. > > ------------------------------------------------------------------------------ > 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 > > ------------------------------------------------------------------------------ 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
