On Fri, 11 Mar 2016 11:20:18 +0000 Tom Hacohen <t...@osg.samsung.com> said:
> 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. because i have limited time and like to get work done is small manageable chunks that each can be done and stand on its own. it is how i have always done things and as my time has reduced the size of chunks has gone down. i do NO T like to maintain a branch locally that i keep having to keep in sync with master. i mentioned all the use cases - caching objects, cross-thread deletion etc. etc. - just because it isn't USED doesn't not mean it's not USEFUL. if we applied this principle throughout all of efl we may as well just remove all of elm api because elm api is not used in efl. it's "user facing". don't add a feature to elm because efl or elm itself doesn't use it. is the feature useful? is it complex? is it hard to maintain? those are the criteria, not "do we use it ourselves in efl - unless we do we won't support it". :) > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
