On Tue, Jul 19, 2016 at 9:33 AM, vi.vorobiov <[email protected]> wrote: > On 07/19/2016 07:07 PM, Cedric BAIL wrote: >> On Tue, Jul 19, 2016 at 8:09 AM, vi.vorobiov <[email protected]> wrote: >>> Yeah, we are understand that this buggy code should be rewritten in >>> different way. >>> Tho, sadly don't have much time to investigate and quickly apply another >>> fix to it. >>> >>> We needed to do that in threads because otherwise it would freeze our >>> beautiful project-opening-animation C: >>> So it was kinda quick-fix-for-now. >> Hum, does it freeze under linux or under windows ? On linux it should >> just do a fork and get the pid, so it shouldn't take to long. On >> windows, I don't know. In all case, Ecore_Exe is supposed to be fully >> asynchronous and should not block the main loop. > Well, I wasn't quite informative on this case... > Inside of eflete stuff we call edje_cc to build up imported edc file, > so eflete have to wait for it's results (compiled edj file from edje_cc) > by using a waitpid. > > I guess that is the One function that freeze our animation > (anim also shows current edje_cc compile process while it works) > if we call that thing in main thread. > > If we won't wait edje_cc results, > then eflete will start to work with not existing project (it's still > building in edje_cc).
Ecore_Exe emit a few Ecore event. One of them, ECORE_EXE_EVENT_DEL is triggered when ecore catch SIGCHLD and do the waitpid to notify you that ecore_exe process exited (You can also get the stdout/stderr and so on). >>> BUT! >>> We found some solution, tried it up, it seems working, just need time on >>> applying it to eflete code. >>> So that "ifdef WIN32" fix is quite temporary decision to just to make it >>> buildable on Windows. >>> >>> I will work on it as soon as will be available to! >> The problem is that accessing the main loop from another thread (which >> is what ecore_exe does), is prone to race condition and memory >> corruption as this is impossible to make thread safe. So you may have >> bugs later on that you have not identified the source of and this >> would be it. > well, now we tried to use > *ecore_main_loop_thread_safe_call_sync* > and actually it does helped a lot, > > it doesn't freeze the animation as well, which is good. But we call it > inside of thread. > So now, it looks more like /"thread" /-> > /"ecore_main_loop_thread_safe_call_sync"/ -> /"ecore_exe"/. It is surprising that your waitpid does work at all as the SIGCHLD should be triggered in the main loop. In all case, what you are trying to do is already provided by ecore_exe :-) -- Cedric BAIL ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
