On Tue, Sep 13, 2016 at 10:53 AM, Davide Andreoli <[email protected]> wrote: > 2016-09-13 2:09 GMT+02:00 Cedric BAIL <[email protected]>: >> On Mon, Sep 12, 2016 at 2:11 AM, Tom Hacohen <[email protected]> wrote: >> > On 08/09/16 23:29, Cedric BAIL wrote:
[snip] >> >> 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. > > I disagree here, really you are saying that only raster use async stuff in > efl? It is a fact that the amount of people using evas image async loading has been very low or there would have been bug report for the past 10 years as we have only finally fixed them for release 1.17. And the only way to have no crash was to have only one image doing async preloading. > >From my POV efl is (and has always been) a fully async toolkit, and I use > lots of async stuff in all my programs: timers, animators, idlers, > ecore_con, > ecore_exe, ecore_fd, edje_signals, emotion callbacks, etc... > > And to be honest I never feel the need for a better async API... The problem of all this API is that there event are custom and needs manual binding/understanding. Also we are talking here of asynchronous request here. Event are by nature async, but when you make a request, you want the result related to that request. More below. >> - 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. > > And this is the second reason that make me scared about promises: > If the call (uri_set in this case) is an async call I expect callbacks > to be called later, not now. My example are describing actual code using Evas event in all our asynchronous API. This is not promise, this is our current code and stack. With promise/future, it would be : future = uri_set(obj, uri1, key1); efl_future_then(future, &cb_done, &cb_error, &cb_progress, cb_data); > If the uri_set implementation permit both the behaviors (callbacks > called immediately, or callback called later) then the user have to > think about both scenarios, making it's job harder. This is our current, 10 year old API. This is how image pixels preloading work (Except you have to do a preload request as a second call after uri_set). > IMO all the async API must have one or more callbacks explicitly > given in the call itself, ex: > uri_set(obj, uri1, key1, cb_done, cb_error, cb_progress, cb_data) > > In this way it's clear that the call is async! Yes and no. The problem is that you are introducing a problem, we can't have custom callback without having manual bindings. This API is also less powerful, you can't synchronize easily multiple piece of code. If for example you are loading an edje file asynchronously, you want to notify whoever instanciate it that every object is now ready. This would have to be done manually inside of edje and trigger the right callback. With future/promise, you would get the future from each object building request, aggregate them into an efl_future_all and return that future to the caller of an async file openning in edje. Another example is to use a timeout future with another request and combine them into an efl_future_race. This enable implementing timeout trivially everywhere. Something you can't do with your proposal, that is otherwise very close to what promise/future are. [snip] >> > 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. >> > > I'm with TAsn, I'm against promise. The simple solution I propose is > that all the async API have the callbacks explicitly given as params. I think you are as confused by the current state of async request in our code base as Tasn, which kind of proove my point ;-) > And a note: > I was trying to keep myself out of this promise discussion, but it > seems not really possible :) What I can say is that I will not discuss > about the internal implementation of asyncs/promise, I will only argue > about the API we are going to expose to the user, and I will fight > for keeping the API as simple as possible. Sure, but I think you should have now reevaluated your position as it is obviously a misunderstanding of the state of our current async API, requirement and what promise/future are/provide. -- Cedric BAIL ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
