On Thu, 07 Nov 2013 13:00:59 +0100 Guillaume Friloux <guillaume.fril...@asp64.com> said:
> On 07/11/2013 09:24, Carsten Haitzler (The Rasterman) wrote: > > On Wed, 06 Nov 2013 14:48:17 +0100 Guillaume Friloux > > <guillaume.fril...@asp64.com> said: > > > >> Hello e devs. > >> > >> When fixing an issue > >> (http://git.enlightenment.org/core/efl.git/commit/?id=838c3bed85535559713e57f6e523da1f73c0ca31), > >> i saw that the error isnt held correctly in ecore. > >> When everything is working, things are quite simple : > >> - You call ecore_con_server_connect(), that will allocate you an > >> Ecore_Con_Server object. > >> - You go in the mainloop, do the stuff you want. > >> - You leave mainloop. > >> - You call ecore_con_server_del() to free your object. > >> > >> But when an error happens, the Ecore_Con_Server object always gets > >> "delete_me" set to EINA_TRUE, and so, in the application using > >> ecore_con, you have to handle this by not trying to free the object in > >> case of an error (while the error can be totally separated from an > >> allocation problem, in my case, non existent domain name). My opinion is > >> that the error event should be raised, without deleting the > >> Ecore_Con_Server object. > >> > >> Also, in the test case i added > >> (http://git.enlightenment.org/core/efl.git/commit/?id=329c64621891f855955eab1794d2d0255c377fcc), > >> you change the timeout set (5 seconds) to something low (1 second or > >> lower), the test case will just segfault. I dont have time to spend on > >> this, but maybe this is related to the strange behavior i have describe > >> above. > >> > >> What do you guys think about it ? > > this would break behaviour that apps would rely on - ie that after a del > > event on a server the object is deleted automatically so the app doesn't > > have to bother. it HAS to listen for del events and mark any handles it has > > to the server to NULL on such a del event... so it doesnt access it > > later... :( > > > I am clearly speaking about breaking how it works. > As far as i know, you always have to free yourself what you directly > create (you dont bother about internal stuff). The only exception i know > on EFLs (i only use the lower level libs) is Ecore_Con_Server. ecore_exe handles work the same. :) > This is an object that you have to handle yourself (allocate and free) > except in the case of a system error or dns error. My question wasnt > about how it works, but is it possible to change this one day or not ? > To me its an exception to everything done, maybe someone can prove me wrong. not quite a single exception. ecore_ipc too does this. and ecore_exe. the problem is that by changing this - we break existing code. and we are trying not to do that. i think this is something we put down for efl2.0 with all the eo stuff and then all objects behave and have the SAME lifetimes that work in the SAME way... :) for this.. ecore_con should use eo... (and ecore_ipc... and ecore_exe etc.)... i am more than happy with the idea that we start to fix the internals of things like these and use eo - but keep current behavior... and then for efl 2... you get exactly what you want. :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
