On Mon, 3 Dec 2012 17:41:39 +0100 Andreas Volz <li...@brachttal.net> said:
> Am Mon, 26 Nov 2012 09:04:52 +0900 schrieb Carsten Haitzler (The > Rasterman): > > > On Sun, 25 Nov 2012 23:23:42 +0100 Andreas Volz <li...@brachttal.net> > > said: > > > > > Hi, > > > > > > I run an application with the Ecore_Exe API ecore_exe_run(). And I > > > have anoption to kill it with ecore_exe_kill(). This works nice as > > > long as the child still runs. If I use ecore_exe_kill() after the > > > child yet ended I get: > > > > > > ERR<11696>:ecore ecore.c:570 _ecore_magic_fail() > > > *** ECORE ERROR: Ecore Magic Check Failed!!! > > > *** IN FUNCTION: ecore_exe_kill() > > > ERR<11696>:ecore ecore.c:580 _ecore_magic_fail() Input handle is > > > wrong type Expected: f7e812f5 - Ecore_Exe (Executable) > > > Supplied: 00000000 - <UNKNOWN> > > > ERR<11696>:ecore ecore.c:583 _ecore_magic_fail() *** NAUGHTY > > > PROGRAMMER!!! *** SPANK SPANK SPANK!!! > > > *** Now go fix your code. Tut tut tut! > > > ERR<11696>:ecore ecore.c:570 _ecore_magic_fail() > > > *** ECORE ERROR: Ecore Magic Check Failed!!! > > > *** IN FUNCTION: ecore_exe_free() > > > ERR<11696>:ecore ecore.c:580 _ecore_magic_fail() Input handle is > > > wrong type Expected: f7e812f5 - Ecore_Exe (Executable) > > > Supplied: 00000000 - <UNKNOWN> > > > ERR<11696>:ecore ecore.c:583 _ecore_magic_fail() *** NAUGHTY > > > PROGRAMMER!!! *** SPANK SPANK SPANK!!! > > > *** Now go fix your code. Tut tut tut! > > > > > > So how will I get information in the father that the child ended? > > > And how could I prevent this failure? > > > > ECORE_EXE_EVENT_DEL events. after this event the exe handle is deleted > > automatically, thus your problem. > > Oh, I really don't like this design. :-( it's there to avoid memory leakages... for when you do lots of ecore_exe_run ()'s and just dont care when the end (thus dont handle the del events). > There is no possibility to check of Ecore_Exe pointer is yet suicide. I > hate this for hiding in C++ wrapper. It's not possible to control > object by life time. I always have to catch the event and check which > one ended. I could even not clear up by ecore_exe_free() if my Exe > object is deleted. Because it doesn't know if it yet died. > > I tried the C++ Exe object to register itself for signals and check if > it self has died and then throw exceptions or mark as invalid. But this > approach had to much problems. > > Why do you delete yourself? as above... imagine something like e17.. imagine for now it didnt look at del events for the exe.. and over its lifetime it spawns 10000's of processes.. u'd leak the handles all day long. :) it's to make it easy for the programmer to not shoot themselves in the foot with a leak. sorry - but it wasn't designed to make life easy to write a c++ wrapper :) p.s. with eo you shoul dbe able to ADD a ref to the exe obj if u dont want this behavior and thus it will get unreffed by the del event.. but still stay around until the last ref is cleaned up. timers, animators job and many other things do the exact same thing. it's a common design pattern in efl. > > > If I knew child ended I could simple not calling ecore_exe_kill(). > > > > yes... ECORE_EXE_EVENT_DEL events. they even tell you which exe > > exited, exit code and s on. :) > > Yes, this works well, but from design point of view my opinion is that > the logic who created an object should be responsible of freeing it > later. > > -- > Technical Blog <http://andreasvolz.wordpress.com/> > > ------------------------------------------------------------------------------ > Keep yourself connected to Go Parallel: > BUILD Helping you discover the best ways to construct your parallel projects. > http://goparallel.sourceforge.net > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
