On Mon, 6 Jun 2016 06:01:13 +0200 Cedric BAIL <[email protected]> said:
> >> >> 2. they are complex to set up inside our api (setting them up setting
> >> >> cancel cb's and more)
> >>
> >> What do you mean by that ?
> >
> > look at Efl_Internal_Promise and then needing Eina_Promise_Owner in there
> > and then the wonder of the cancel callback deleting the obj which then also
> > cancels and double-frees and segfaults. promises are totally unsafe.
>
> Yes, there is some security to add to promise, not a big deal. We need
> to prevent double cancel and prevent reiteration. Added with the magic
> check, should be already pretty much fixed for everything you just did
> describe.
there should be much more. it should be in the eo obj id table or you should
implement a whole new one just for promises. or make them eo objects and one
way or another have promise callbacks work.
> >> You just can't do with eo event what promise do. Eo event are a
> >
> > it's not NECESSARY to do anything new. timeout can be an eo obj that deletes
> > itself after the one-shot callback. it doesn't need a promise. same as job.
> > i can't add promises as children to an obj and make sure they get
> > autodeleted when parent is. i have to do this all by hand now.
>
> It is a terrible mistake to override eo object lifecycle. This is an
> absolute no go as a solution. Anything that bypass the refcounting and
> ownership of an eo object lead to massive issue and trouble. We can
> not implement auto deletion of eo object outside of the reference
> count system.
this doesn't bypass it. it USES it. the object unrefs/del's itself. when done.
when an evas canvas is deleted it deletes all child objects. no code is
explicitly in the app deleting the objects. it's done internally.
> > efl model needs to drop promises. ask sanghyeon and sub - they are hating to
> > work with the promises in efl model - it's massive overkill and unneeded.
>
> If you read the ongoing discussion regarding MVC and the view list
> code, you will see that the problem is not the promise, but the fact
> that the model is fully asynchronous and that they have to handle it.
> Dropping promise out of the model, and they will not only hate, they
> will want to jump by the window.
it's both. async made it more complex than sync AND promises require a unique
promise per property on a model object when a simple "property loaded" event on
the model object would do just fine. the one cb can refresh the item mapped to
the model object in whole and a property get can just return null etc. if the
property is not loaded yet. property content has to in the end be cached in the
model object anyway so this ends up simpler and you don't need a promise nor
the value - the value is already living in the object under the property.
> > efl model would be far simpler with just the model objects having an api to
> > queue a fetch for a property and a property "fetched" event callback. they
> > don't NEED promises. a get of a property returns NULL until the property has
> > been fetched and stored. it's far SIMPLER to design and use WITHOUT
> > promises.
>
> NO IT WILL NOT. As I have said, it was what we had before promise. The
> code was 30% bigger everywhere in the MVC stack. It was more buggy,
> more difficult to fix and more difficult to extend. We already have
> the experience of that change, and it was really awful.
having to have a new promise per property and per new range get isn't needed.
you can have a simple "new child range" event on the parent obj. as above for
properties.
> > please talk with the people USING promises. no one likes them at all right
> > now except for you and felipe.
>
> Well, I have put Subhransu in copy, I like to hear his version.
see above.
> >> repeated event which doesn't allow any easy synchronisation and lead
> >
> > wrong. you can in the callback just do the next action and delete yourself.
> > it is possible to do this easily enough. but this isn't the common case.
>
> Yeah, this is going to make life easier by writing more code that is
> likely to be the source of more problem.
and eina_promise isn't more code? it's new/different to the rest of events and
objects? eina_promise objects have no safety and ate causing crashes now where
none were before and will continue to cause more and more and more. it will
cause much more time spent debugging and complaining that efl is "horrible" and
"hard".
> >> to race condition. Promise do allow easy synchronisation and avoid any
> >> race condition. They make life easier on that side. The price to pay
> >
> > and they are a pain in the butt to work with in their current incarnation.
> > the medicine is WORSE than the disease.
> >
> > please speak with the people using promises. they are worse than what they
> > are trying to cure.
>
> There are 3 pieces of code that have fully asynchronous behavior in
> EFL. elm_store, that you did write. MVC that Felipe did write and evas
> async preload of image that I did write. I have not seen any
> application using elm_store as a fully asynchronous MVC in the past as
actually because i didn't document is and finish it - it was a demo of how of
course you can do a fully async list with genlist with no blocking. it's not
because it's hard.
> it was to difficult. Felipe had a huge pain to implement the
> asynchronous behavior in the MVC using eo event. Finaly myself I
> remember how long it took to finally fix it (it was properly fixed
> this year). The fact that we don't have any proper infrastructure to
> handle asynchronous behavior correctly over the last decade should
> have told you better than just it was fine.
that's utter bollocks.
> Basically nobody use image preload or elm_store, because it is a pain
this absolutely false. *I* used preload myself. it was simple to use. how do you
think terminology managed to not block when displaying popup images and zooming
scaled svg's, pdf's and more? preload was used. just grep around. it was simple
to use and promises do not improve its usage at all. they make it worse because
now we have a promise as a new object that is not safe - it's an EXTRA thing to
keep track of where before i had only ONE thing to track - the image object and
if the preload was done or not (the event). i used preload in rage. i used it in
enlightenment.
store wasn't used because it was not complete, tested or documented.
> to implement the asynchronous behavior. Writing a new data model for
> MVC has also been a huge pain until we switched to promise. So yes, I
> have been experiencing first hand what writing asynchronous code is.
> Same goes for Felipe. I am not going to switch away of a solution that
> make our life seriously easier. I will improve the solution, but not
> walk away from its design. It is way way way easier to implement
> safely asynchronous behavior with promise than with your proposition.
> This has been tried and the outcome has been clear for anyone involved
> with that previous experiment.
eina_promise is not ready. it's unsafe. it's more complex. it's a new kind of
object that doesn't behave like any other object and lacks the safety and
convenience. if you say objects' can't delete themselves then what on earth are
promises? are they not objects? are they not something you hold a handle to so
you can cancel them or otherwise interact with them? do they not have a
lifecycle? are they not created and destroyed like eo objects? ye somehow
promises can delete themselves (e.g. the eo timer object a timeout created was
deleted then the promise is deleted silently on its own in the background...)
you are totally inconsistent thinking promises are some kind of magically
special thing that is not an object... yet in all ways it works *IS* an object.
> > promises are not eo objects. they cannot be managed in the lifecycle of
> > object. jobs and timeouts now need special handling. the promises for
> > models are not eo objects so you have to specially handle them if you want
> > to cancel and there actually just is little point in doing so actually.
> >
> > you can't make promises weak refs. you can't add them and children to a
> > parent for auto-deletion. they can't be easily extended (adding more events
> > to a promise) like eo objects can.
>
> You never want weak refs, you don't want either parent/child
why do i not want them? tell me? why do they even exist then as an idea and why
are they in eo? if i want a weak ref then that's what i want. i want a handle
that the object system will set to NULL for me when the obj is deleted so i
don't have to do that by hand by adding a del callback and nulling the ref
myself. so... why don't i want them? i can tell you that e, efl etc. is full of
this kind of "track del event and NULL a ptr" code. it's all over the place.
so... why?
> relationchip or any kind of reference counting like that. This is
why not? if i have an async actin. let's say its slow like downloading an ISO
image file. do i not want to have that promise cancelled/deleted when the window
dealing with that download is closed/deleted? sure if i want ti to go on in the
background, the parent won't be a widget in the window....
so how do i not want this kind of relationship like other objects?
> already something we learned. The only think we may want is to link a
> promise with the lifecycle of an eo object to have cancel called on
> that object del (Yes, anything else is likely going to break something
EXACTLY. and that is what happens if you just add it as a child to that object.
PRESTO.
> when handling asynchronous stuff). And implementing that behavior in
> Eo is going to be a pain (disabling refcounting, disabling
> parent/child, ...).
eh? don't disable refcounting. in fact WTF is this?...
EAPI void eina_promise_ref(Eina_Promise* promise);
EAPI void eina_promise_unref(Eina_Promise* promise);
you speak of not refcounting yet eina promise has RE-IMPLEMENTED reference
counting just like eo. i can't take what you say here seriously. if you say
promises are not objects and should have no reference counting because they are
oh so special yet... right there in eina_promise is EXACTLY THAT. eina promises
are re-inventing eo objects thinking they are oh-so-special not-object-objects.
> >> Also last point, I think having the same signature, would actually be
> >> more confusing to people. Like why does that event not accept to be in
> >> a promise_all or promise_race ? If it has the same signature, people
> >> would expect to be able to use random event in promise_all/race and
> >> that is just not doable.
> >
> > the number of times people actually NEED these is insanely rare. no one is
> > using them. these "features" cause more pain than it's worth. speak to the
> > people using promises now.
>
> Ofcourse they don't need it, they never write any asynchronous code.
> Almost none of our API is asynchronous and when they can they run away
no. i am speaking of the cases where promises have crept in. timeouts are not
needed when timers will do. jobs could just be objects like timers that
self-del after calling their "done" callbacks. eina_model could work without
promises just fine (see above). any kind of event with "do something now and
later some event happens as a result" is async. we've had this in efl for ages
in several corners. edje objects are async by design. signals are queued and
will pop out later in their callbacks. i shouldn't have to tell you this. edje
- one of our biggest cornerstones of everything we do is async. preload -
async. jobs - async. timers - async... ?
> screaming. How many people did implement something like elm_store in
> their application to have a fully asynchrone application ? None,
> because it is a huge huge pain. How many people do implement
> asynchronous image preload ? Not much more...
but the promises we have are a worse solution than just some event callbacks in
model - for example. jobs and timeouts are pretty bad to use now. i have a
job ... i have to track it as an object and rememebr to cancel it when the obj
the job was for dies. the whole POINT of eo and parent/child deletion etc. was
to STOP THIS. now it's just worse than before. at least before the code was
simpler. now it has the worst of both worlds. much longer/more code ANd manual
tracking of child objects and doing the deletion yourself.
> > why should a timer be so DIFFERENT to a timeout? why should it be a special
> > thing with a whole different way of working with promises? why add the
> > complexity? just set a timer to NOT REPEAT on creation... having all the
> > code for a timeout is needless complexity in our codebase AND in the api as
> > people have to figure out a completely different way soemthing works.
>
> So your point is to have the timer just stop emiting event and you
> have to kill it manually afterward. Doesn't look any easier to me. You
no. it just deletes itself. promises do just this already!
> have more code to write and more chance to go wrong. The fact that
no you don't have more code. well "more" would be to set he timer to not repeat
on creation.
timeout = eo_add(parent, EFL_TIMER_CLASS,
efl_timer_repeat_set(eo_self, EINA_FALSE), // this extra line
eo_callback_add(eo_self, EFL_ACTION_DONE, callback, NULL);
with timers being eo objects and timeouts being promises i have 2 vastly
different pieces of code than i have to learn about 2 different kinds of
objects that work differently and use different api's.
> they don't do the same thing, means they are not the same. We could
> sure merge everything together by this standard. Not going to make
> anything easier. Having explicitly different object for different
> behavior make things easier, not the opposite. Otherwise we should
> merge back all this image object, because they all display pixels in
> some way or another.
it make's it harder to learn, more api's to learn, difference to figure out,
which do i use where etc. etc.- you add a learning curve that is simply not
needed. don't want ti to repeat? turn repeat off once above on creation.
> > but PROMISES are the proble. the promise is a fragile eina structure with no
> > safety and everyone is having shit segfault and be trouble on them. it adds
> > huge amounts of code to their work. just ask them. i'm telling you. i've
> > spoken with them.
>
> You may have, but you may have not listened to their problem. So far,
i HAVE listened. the find async hard. they complain about 2 levels of async
too. but they ALSO complain about promises as well. the promises make the async
worse.
> the problem that I got described are: "It is to asynchronous, we want
> result directly.". That is not going to happen and with your
> proposition it will be just worst. Been there done that, not going
> back there any time soon.
how will it be worse? the model object stores its properties? a gegt is an
immediate get from the stored property data? you use events just to indicate
new property data arrived? (event info can indicate which property it is that
arrived if they care)? how is that worse?
> > which is why i say - don't use promises at this stage. they are far from
> > ready. if anything they need to be eo objects. eo objects with events for
> > then/fail/whatever. and many if not all cases where promises are used now
> > just do not need them.
>
> No, no and no ! As explained again above, moving to eo object require
> to break eo object behavior for everything or it will go wrong. As for
> your statement that you do not need them, sure we don't. We lived
> without them before, and nobody did implement any asynchronous
> behavior in their application, because it was a serious pain. If you
> want to go that route, then we should remove all asynchronous API.
> That's it.
i've gone into this above how it doesn't break eo object behaviour.
> > see above for model. same for job and timeout. they don't need them. i
> > haven't looked at eldbus or eio but i think its pretty much the same deal.
> > you don't need them.
>
> It's pretty easy, just git log -u on the any of the model and the
> elementary view to see how much more work it was before the promise
> (Keep in mind that it was also buggy and more difficult to
> develop/fix). You proposition has been tried in the past and it has
> been a complete failure.
it has not. let's go to a long standing one - preload. that has been around a
long time and how has it been a failure? explain it to me. we won't talk model
as it barely has even existed or been used long enough to say.
> > this is the same as eina_promise. i have to do eina_promise_then() AFTER i
> > get the eina promise back - eg from job or timer. but what you do is you
> > dont need a promise at all above you just do:
> >
> > eo_callback_add(image, EFL_IMAGE_EVENT_LOAD_SUCCESS, cb, NULL);
> > eo_callback_add(image, EFL_IMAGE_EVENT_LOAD_FAIL, cb, NULL);
> > efl_file_set(image, "tot.jpg", NULL);
> >
> > i set up to listen before i do the action. simple. it works WITHOUT a
> > promise.
>
> Thanks for an example that doesn't work. Either you add a call before
> registering all the callback to force synchronise the previous
> possibly running file set or you have to handle in both callback the
err how does it fail? you dont dd cb's every time you file_set. are you mad?
the code that is controlling the file set sets up the cb's once and listens for
when things succeed or fail, then does something appropriate. how does this
fail?
> case where the event you receive is not for the file you are just
> opening after. So your example is misleading on the complexity on
how is it misleading? you set up cbs once. you file_set. any new file_Sst
cancels a previous one so no cb will be called for any previous ones. any cb's
called after that are for the last file_set. how does it fail?
> purpose. Oh and with promise their would be no misleading behavior as
> the previous promise will have automatically been cancelled and the
it isn't automatic. the file_set explicitly tracks the previous promise and has
to cancel it. it's the exact same thing.
> new one will have been completely independant. Thanks for giving me a
> good bad example with your proposal and why people have not implement
> much asynchronous behavior with our current API.
wtf? it's no more code at all. it's 2cb's added as event cb's and a file_set. i
don't have an ADDED promise object to deal with at all. it's simpler. not more
complex.
> > hook up the cb's after return. is you pass in an empty promise obj to "take
> > control of" instead as a design then that works too - just add cb's FIRST
> > or if you return promise objects, do not "instantly do" the action until
> > later. just add a "do" method to the promise obj to say it's ready to begin
> > its async action. you have the problem either way, but eina_promise is
> > totally unsafe, it's a pain for lifecycle management and it's impossible to
> > extend in apps or outside of efl AND the whole binding system.
>
> As said above, you do not want the same lifecycle management as with a
> normal eo object. You want your promise to be cancelled when any of
> its needed relationship is deleted. Any other behavior will break the
> promise in a way or another. You are clearly making a very strong
> point for not following your proposal by giving example and use case
> that are missleading to anyone that will use them directly. I don't
> see how this make a good case at all to get rid of promise.
eo objects can do this too. what's new?
> >> is no way to get any event. Ofcourse, we can override the behavior of
> >> events on this eo_promise completely. Now let's imagine, that we
> >> actually do always store the events, so that everytime someone
> >> register a callback we can send the event. Still you can't auto del
> >> the object at any point in time, you have to force the user to
> >> implement the eo_del and to always provide both a then and cancel
> >> callback.
> >
> > you have the same issue with eina_promise if you return it. EXACTLY THE
> > SAME. it has no cb's for then/fail yet.
>
> No, promise keep in memory the result until you register all the
> callback you have planned to register. There is no race condition at
> all. That is why you pass a free method when you set the value. It is
> to clean it later on and to keep it around until you are done. So no,
> it is NOT THE SAME.
and if you pass in an eo promise object it can be done similarly - just set up
cb's on the promise obj before passing to the action. the model stuff works
this way - promises are passed in not returned.
and you can do the same with eo - you can store the result until cb's added or
until a go/done/whatever api is called. but that on;y matters if you want a
specific cb for that specific action. in general if you want that hen you want
a real object to be returned so you can manage it like other objects.
> If history tell us, our existing solution is not usable, but prove me
> wrong and show me how amazing our current limited set of asynchronous
> API is used by so many people. Now just think that we are expanding
as above. ecore_con. ecore_con_url, preload, timer, job, animator, .... all
used.
what we learned is these are objects that need tracking and that is a pain and
that is why we have eo. you are now choosing to abandon that lesson with
eina_promise.
> the amount of async API and image the result. I see it already, as
> many data model as we have user of elm_store, as many view as we have
> user of image async preload, ... I can see that success already.
we have very little async api. almost all of them are used.
we're repeating here.
eina_promises are objects. they just refuse to be eo objects and so be totally
different in usage. this is bad. it means no safety. it means different
callback signatures etc. - as above. this is worse than what we had with eo
until promises turned up. far worse. and it's worse than legacy api because you
lose the benefits of eo AND make the code longer.
...
> No, you didn't, I did. You completely missed the problem. The issue as
> to do with timer that have a problematic lifecycle. Historically timer
> where automatically destroyed by the main loop when the main loop was
> destroyed. This behavior is still there and by pass the ownership
> behavior of eo reference (like your proposal for having an
> automatically deleted eo object). So I needed to watch for the timer
> to vanish under the feet of the timeout. This was badly done on my
> side as I was just watching the DEL event on the timer. Obviously any
> eo_del o the timer does lead to that event, which created the double
> free. Promise could be more resistant and prevent double cancel and
> double value set (which they will soon), but the main fix is to fix
> the timer lifecycle properly and watch the main loop deletion, not the
> timer destruction. So your analysis of why promise is bad is based on
> a lifecycle issue on an eo object which is doing exactly what you
> recommand to do. Seems like you should revise your proposal as it did
> obviously misslead you into not fixing a bug properly.
umm i sat here and looked at the backtraces. i sat in valgrind. you cancel
promise. it dels' timer obj. del cb on timer then wants to cancel promise
again. then it falls over in a big stinking heap. i shortcut it so on cacnel
this loop wouldn't happen. it worked. it didn't leak. but it points out how
fragile promises are.
> The only think I see from this bug that could be improved, is to maybe
> add a facility to automatically cancel a promise when an eo object die
> (something to discuss with Tasn separately) and make sure you can't
> double cancel/set value on promise (which will be done this week).
> Also making sure that no eo object has a weird lifecycle seems to be
> absolutely mandatory (So the timer lifecycle will be fixed and we
> should make sure none of the other look object does behave life that).
they should be eo objects.
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) [email protected]
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
