On 10/03/16 23:29, Carsten Haitzler wrote: > On Thu, 10 Mar 2016 16:07:58 +0000 Tom Hacohen <t...@osg.samsung.com> said: > >> On 08/03/16 13:39, Tom Hacohen wrote: >>> Hey, >>> >>> Wouldn't it better if the intercept function could return a value saying >>> "actually, the object is good to go, just delete it normally", like in >>> your example, if the object is already in the right thread, it should >>> just delete immediately, no? >> >> To be honest, giving it a bit more thought I don't see how that is >> useful. I think that it's an extreme corner case that is not worth the >> trouble, and I'm very much against adding this kind of API because we >> actually have uses for them. I'm talking about code using them. Adding >> this won't break API so we can wait with adding it until when we >> actually need it. > > actually it will be used soon - specifically for generic messages between lop > objects. this is the only way to ensure "safe destruction" of an Eo * payload. > >> An alternative would be to deal with the cleanup in the destructor. So >> you for example free data that is thread agnostic, and when you have >> code that needs to be run in a specific loop, you can set manual free >> and defer the cleanup to that thread, so most of the object is >> destructed in the destructing thread, but the relevant parts are cleaned >> in the correct thread. This is implemented per object and is much cleaner. > > this is far more complex than just queing the deletion as a whole on another > thread. > >> I like it better, but even if we choose to go with the idea in this >> commit, I'd say: revert it until needed. I talked to Felipe about it on >> IRC and he agrees. > > see above. i added this because it will be needed soon. like in the coming > weeks/months.
My point is, and it's a point I make all the time about API design. Why not add it when *actually* needed (not a week before or a month before)? This ensure the API is actually good and doesn't end up unused. Preferably it should be used by someone other than the original author to ensure it's at least usable. I don't care enough to argue about this one, because it doesn't harm any of the Eo hot paths, but I still think it's a bad idea to introduce it so early (and in this case, a bad idea in general). -- Tom ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
