On 13/09/16 01:09, Cedric BAIL wrote: > On Mon, Sep 12, 2016 at 2:11 AM, Tom Hacohen <t...@osg.samsung.com> wrote: >> On 08/09/16 23:29, Cedric BAIL wrote: >>> So I have now landed Efl_Future and Efl_Promise as previously >>> discussed in a lengthy email thread. The split was necessary to make >>> it possible to handle the lifecycle using eo object. This >>> implementation simplify and clarify the API compare to the eina api we >>> have. >>> >>> Still there is some strong concern for me. Efl_Promise/Efl_Future are >>> primitive that shall not be inherited from as they require manual >>> binding in every language to take advantage of native asynchronous >>> behavior as defined in that language. I have given up on Efl_Promise >>> not being in an .eo file, but not Efl_Future. >> >> First of all, you should make both .eo files, I already mentioned it on >> IRC. Creating classes manually is discouraged! > > Yup and to repeat my point here, I want to make that nobody mess with > efl_future in any way that could break bindings. There is basically > absolutely no way to modify an efl_future behavior without resulting > in binding not able to pick the new behavior. efl_future are what > define asynchronous behavior, altering them is a sure receipt for > borkage and I see no win for a simple, well defined and limited class > to be in a .eo file.
I would like to clarify: all I'm saying is, don't create classes manually, if you don't want them to be inherited from: that's very easy to check in the constructor (you do class_get and make sure the class is correct), and in compilation time (don't ship the .eo file > >> Second, I still don't quite understand what you mean by this statement. >> C++ is a language that doesn't have native async behaviour (for all I >> know), automatic binding for that would work just fine (though maybe a >> bit odd looking and better to go with the native promise interface). I >> also have no idea what you mean by no-inherit, what's the problem if >> someone decides to inherit from a promise and override it a bit? Change >> some behaviour in the constructor or whatever? > > Inheriting from efl_promise is a maybe safe behavior. I say maybe > here, which is why it is in an .eo file. Still I will strongly > discourage to do so as some language may not be able to pick up the > altered behavior. It is still less of a problem than efl_future. As > for automatic bindings, it obviously can not work, especially for C++, > as there is no possible type information defined in .eo and you need > to implement efl_promise as a template. > > The second reason, to the opposite of what you believe, C++ and its > standard library do come together and promise/future is part of it and > defined the way to have asynchronous behavior in C++ with threads. Our > take on it is compatible and extend it to be integrated with efl main > loop. So you do have a notion of native async behavior. This is off the point, so I'll just drop this branch of the conversation. I don't really care if you want to block inheritance, I was just curious. > >> Regardless of the above, it should still be in a .eo file, just not >> shipped (making it essentially private). *NOT* done manually. > > Please give argument as to why it should and what benefit we would > get. For now I see to much draw back and no win. Most obvious benefit: I had to manually change your code because I optimised some things in Eo. If you use .eo files, you'll automatically get any optimisations that are gotten into Eolian. If you do it manually, you won't. Also, manual is more error-prone. > >>> The reason is that Efl_Future being an Eo object make just absolutely >>> no sense in any context. The only feature we are really using is weak >>> reference and refcounting when setting multiple callback on the same >>> future. Other than that we do not rely on Eo at all. It require its >>> own event propagation and reusing Eo event prototype make the API less >>> usable actually as we need to do a double cast prone to error in my >>> opinion. I do also have serious concern on speed and it might affect >>> us in the future when we start using this more. Remember how genlist >>> scrolling benchmark is spending more time in eo function than >>> rendering, not going to improve with this. >> >> Could you give examples of the double-cast? The idea is to have a >> unified API, and not have you reimplement weak-refs and refcounting yet >> again. Same with callbacks. > > weak-ref and refcounting are very simple behavior to provide. Not > really valluable. As for double cast, you can see it at : > https://git.enlightenment.org/core/efl.git/tree/src/tests/eio/eio_test_manager.c#n25 > I initially misunderstood the scope of promises, and I think almost everyone who voted to have it as an Eo object did too. The first proposal we saw had refcounting built in, so we thought you wanted to reimplement life-cycle. It is now clear, however, that life-cycle for promises does not make any sense. Promises should not have refcounts at all, not weak and not "regular". It should probably not be an object at all, just a structure. See my other email, I sent at 12:42pm UTC today (in the last hour). This is more similar to the syntax initially proposed by Felipe. That with the two variants (with promise and without) for each API that would implement promise feels sensible. Though at this point, I'm even potentially happy with one variant, and just passing NULL assuming that promises used scarcely (they should anyway). >> Benchmark, benchmark, benchmark... > > Seriously, you want me to point out how slow this is ? It is pretty > obvious that the cost of getting through the id allocation, eo call > will always be above the one of a direct malloc and direct call. Now, > I don't believe myself in micro benchmark. So we will go and convert > all the various data model we have, implement the MVC on top of it and > then you will have a real life benchmark to optimize for. Is that a > deal ? :-) ... > >>> In any case this is better than our event model based model for >>> asynchronous request as it ties the result to a specific request. >>> There is less risk for the user to forget handling the previous >>> request or setup there event handler to late. Now, what would be >>> interesting is to see how to integrate that with Gustavo proposal on >>> channel in separated thread. >> >> I don't understand why you keep on saying this. There are other ways to >> solve async, it just so happens that "promises" are trending nowadays, >> but there are other solutions. > > The only other solution you have pointed out is events as we have been > doing it for the last 10 years and as I have pointed out is barely > used by anyone except raster as they are seriously difficult to get > right. I can repeat the example here. > > - First scenario, with no previous request going : > > uri_set(obj, uri1, key1); > callback_add(obj); // You missed the instant resolution if the file > was in cache. > > - With a request already going on : > > callback_del(obj); // To be sure that the previous handler are not > going to be called > callback_add(obj); // Here your callback will be called twice, once > for the previous request that is done and once for the new request > uri_set(obj, uri1, key1); > > This is the current API of elm_image and it isn't used correctly by > most people (especially in genlist reuse cache scenario). It is also > the API of evas image and has I have been repeating myself for months > now, it hasn't been seriously used until 1.17 and was completely buggy > (It is still not used that much more as we have problem on Mac OS X). > > The fact that events are not linked to the request being made do > increase the difficulty for users. If you return an handler to the > request, which is what a future is, you make it easier for the user of > the API to follow the flow correctly. Added with Gustavo efl_watcher > it might even be possible to make that linear in a thread. > >> Just to clarify, I'm still against promises (in C). :) > > Please clarify what would be your proposal in that regard as being > against new things without proposing a solution is not helping. > ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
