On 04/05/16 02:40, Carsten Haitzler wrote: > On Tue, 3 May 2016 09:23:29 +0100 Tom Hacohen <[email protected]> said: > >> On 29/04/16 18:11, Carsten Haitzler wrote: >>> On Fri, 29 Apr 2016 05:57:51 -0700 Tom Hacohen <[email protected]> said: >>> >>>> tasn pushed a commit to branch master. >>>> >>>> http://git.enlightenment.org/core/efl.git/commit/?id=9195d008dad901645bebfc83e240649c6b4c69e0 >>>> >>>> commit 9195d008dad901645bebfc83e240649c6b4c69e0 >>>> Author: Tom Hacohen <[email protected]> >>>> Date: Fri Apr 29 13:13:00 2016 +0100 >>>> >>>> Eo keyed data: No need to register to see if a subobject was deleted. >>>> >>>> This is completely unnecessary. We are holding a reference to the >>>> object, it can't get deleted under our feet. >>> >>> WRONG. >>> >>> eo_key_obj_set(a, "key", b); >>> eo_unref(b); // release last ref to b so the key is the only owner >>> // ... some time later >>> eo_del(eo_key_obj_get(a, "key")); >>> >>> perfectly valid. i can unref/del an obj handle i fetched. it may be >>> unwise/incorrect, but i COULD have coe that does the above. yes i SHOULD do: >>> >>> eo_key_obj_del(a, "key"); >>> >>> instead but it CAN happen like above and the code was clearly written to be >>> robust for such cases. you have made code more fragile. >>> >>> because of the other commits now i can't revert without a whole bunch of >>> conflicts. please don't make code more fragile. yes i know eoid makes the eo >>> handle robust, but there still is a CHANCE of it being a misdirect (be a >>> valid eoid pointing now to the wrong object when gen count is recycled AND >>> the eoid table entry is re-used and it happens to get gen count to match). >>> the code handled this case and would ensure there is NOT a clash. now it >>> can happen thus is more fragile. >>> >> >> I can put it back in if you want, the problem is with this approach you >> mentioned here, like many other approaches is that you are *again* >> fucking with correct lifetime handling. > > i said it was incorrect - but it's valid code. just like we have eoid's to > deal > with bad lifespan handling and mistakes... that's why i had it listen to > deletes. in case this happens.
Thanks to eo id those things are not fatal (no crashes) and print errors (so people know there is something wrong), I don't see the point of having this callback if you say all it is for is for printing errors (did I understand you correctly? because it doesn't add to safety). -- Tom. ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
