[E-devel] [YAPT] Promise instant resolution

[Davide Andreoli]

I'm starting this new thread to further discuss promises, thus the tag
[YetAnotherPromiseThread] :)

It seems to me we are putting too much ideas/discussion in the other
threads in a so sparse way that is starting to be difficult to follow the
discussions and to understand when we found some agreement, so please try
to don't go off-topic in this one.

The topic here is: do we really want to allow instant resolution of
promises?
For "instant resolution" I mean a promise that will call the user callbacks
as soon as the callbacks are "connected", thus in the middle of the user
code. (we took as an example a cached promise value)

I read lots of JS promise docs in these days and one that I like is:
https://promisesaplus.com/

Especially I'm pointing to:
2.2.4 onFulfilled or onRejected must not be called until the execution
context <https://es5.github.io/#x10.3> stack contains only platform code

This point (as explained better on the site) means that "instant
resolution" is forbidden in JS.

I know we discussed this already, but it's a point that still scare me and
I fully understand why it is forbidden in JS. From a user perspective pov
having to think at both possible code flow that we are allowing (promise
callback called NOW, in the middle of the code where you define them, or
callback called later) can be really difficult to get right and error prone.

Also if we go to an "always async resolution" approach we can probably
remove lots of complexity in the promise implementation and in the promise
API.

So what do you think? really we need this double-possible-behaviour in our
promise implementation?
------------------------------------------------------------------------------

[Felipe Magno de Almeida]

On Thu, Sep 29, 2016 at 12:38 PM, Davide Andreoli

Post by Davide Andreoli
I'm starting this new thread to further discuss promises, thus the tag
[YetAnotherPromiseThread] :)

[snip]

Post by Davide Andreoli
The topic here is: do we really want to allow instant resolution of
promises?
For "instant resolution" I mean a promise that will call the user callbacks
as soon as the callbacks are "connected", thus in the middle of the user
code. (we took as an example a cached promise value)

I think the fulfillment must happen immediatelly and the user
of the promise must be able to value_set/fail immediatelly.
However, as raster has mentioned some place else, the callback
call could be delayed to the next event loop idler or job, so
the callback is not called directly from efl_promise_then.

I'm not sure what cedric has implemented, but both cases are valid
IMO. However, calling from the next event loop job/idler is a lot
easier to reason about it, so I'm inclined to like it better.

[snip]

Regards,

[Felipe Magno de Almeida]

On Thu, Sep 29, 2016 at 12:57 PM, Felipe Magno de Almeida

Post by Felipe Magno de Almeida
On Thu, Sep 29, 2016 at 12:38 PM, Davide Andreoli

Post by Davide Andreoli
I'm starting this new thread to further discuss promises, thus the tag
[YetAnotherPromiseThread] :)

[snip]

Post by Davide Andreoli
The topic here is: do we really want to allow instant resolution of
promises?
For "instant resolution" I mean a promise that will call the user callbacks
as soon as the callbacks are "connected", thus in the middle of the user
code. (we took as an example a cached promise value)

I think the fulfillment must happen immediatelly and the user
of the promise must be able to value_set/fail immediatelly.
However, as raster has mentioned some place else, the callback
call could be delayed to the next event loop idler or job, so
the callback is not called directly from efl_promise_then.
I'm not sure what cedric has implemented, but both cases are valid
IMO. However, calling from the next event loop job/idler is a lot
easier to reason about it, so I'm inclined to like it better.

BTW, this is how one of the first implementations of Eina_Promise did.
We later decided to remove the dependency of loop from Eina_Promises,
so this delayed callback call was not possible anymore.

Post by Felipe Magno de Almeida
[snip]
Regards,
--
Felipe Magno de Almeida

[Gustavo Sverzut Barbieri]

Next mainloop iteration is essential to make user code "always work", no
special cases.

This was in my other thread commentary about "resolved promise", that is,
to return a promise with a well known (resolved) value

Em quinta-feira, 29 de setembro de 2016, Felipe Magno de Almeida <

Post by Felipe Magno de Almeida
On Thu, Sep 29, 2016 at 12:38 PM, Davide Andreoli

Post by Davide Andreoli
I'm starting this new thread to further discuss promises, thus the tag
[YetAnotherPromiseThread] :)

[snip]

Post by Davide Andreoli
The topic here is: do we really want to allow instant resolution of
promises?
For "instant resolution" I mean a promise that will call the user

callbacks

Post by Davide Andreoli
as soon as the callbacks are "connected", thus in the middle of the user
code. (we took as an example a cached promise value)

I think the fulfillment must happen immediatelly and the user
of the promise must be able to value_set/fail immediatelly.
However, as raster has mentioned some place else, the callback
call could be delayed to the next event loop idler or job, so
the callback is not called directly from efl_promise_then.
I'm not sure what cedric has implemented, but both cases are valid
IMO. However, calling from the next event loop job/idler is a lot
easier to reason about it, so I'm inclined to like it better.
[snip]
Regards,
--
Felipe Magno de Almeida
------------------------------------------------------------
------------------
_______________________________________________
enlightenment-devel mailing list
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[Tom Hacohen]

Post by Gustavo Sverzut Barbieri
Next mainloop iteration is essential to make user code "always work", no
special cases.
This was in my other thread commentary about "resolved promise", that is,
to return a promise with a well known (resolved) value

I completely agree, except for one problem. We still have atrocities
like "ecore_mainloop_iterate" that let the user run the loop inside of
the context and not in the platform code. :(

--
Tom.

------------------------------------------------------------------------------

[Carsten Haitzler (The Rasterman)]

Post by Tom Hacohen

Post by Gustavo Sverzut Barbieri
Next mainloop iteration is essential to make user code "always work", no
special cases.
This was in my other thread commentary about "resolved promise", that is,
to return a promise with a well known (resolved) value

I completely agree, except for one problem. We still have atrocities
like "ecore_mainloop_iterate" that let the user run the loop inside of
the context and not in the platform code. :(

put that thing back in it's box! it's making my eyes bleed! aaargh bleeding
bleeding all the blood! nooooooooo

[Carsten Haitzler (The Rasterman)]

On Thu, 29 Sep 2016 12:57:24 -0300 Felipe Magno de Almeida

Post by Felipe Magno de Almeida
On Thu, Sep 29, 2016 at 12:38 PM, Davide Andreoli

Post by Davide Andreoli
I'm starting this new thread to further discuss promises, thus the tag
[YetAnotherPromiseThread] :)

[snip]

Post by Davide Andreoli
The topic here is: do we really want to allow instant resolution of
promises?
For "instant resolution" I mean a promise that will call the user callbacks
as soon as the callbacks are "connected", thus in the middle of the user
code. (we took as an example a cached promise value)

I think the fulfillment must happen immediatelly and the user
of the promise must be able to value_set/fail immediatelly.
However, as raster has mentioned some place else, the callback
call could be delayed to the next event loop idler or job, so
the callback is not called directly from efl_promise_then.
I'm not sure what cedric has implemented, but both cases are valid
IMO. However, calling from the next event loop job/idler is a lot
easier to reason about it, so I'm inclined to like it better.

however you slice and dice it, *IF* we called immediately and didnt defer we'd
break JS promise rules in our JS bindings, thus basically our JS bindings are
broken by DESIGN of the core lib. so either:

1. don't use/expose promises at all in js - then we don't have to follow their
rules
and/or
2. defer always even if it's just a job to do the defer (it's still called
before mainloop is done and goes idle - thus before rendering starts).

Post by Felipe Magno de Almeida
[snip]
Regards,
--
Felipe Magno de Almeida
------------------------------------------------------------------------------
_______________________________________________
enlightenment-devel mailing list
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[Cedric BAIL]

Hi,

Post by Davide Andreoli
I'm starting this new thread to further discuss promises, thus the tag
[YetAnotherPromiseThread] :)

:-)

Post by Davide Andreoli
It seems to me we are putting too much ideas/discussion in the other
threads in a so sparse way that is starting to be difficult to follow the
discussions and to understand when we found some agreement, so please try
to don't go off-topic in this one.
The topic here is: do we really want to allow instant resolution of
promises?
For "instant resolution" I mean a promise that will call the user callbacks
as soon as the callbacks are "connected", thus in the middle of the user
code. (we took as an example a cached promise value)

What we want is to be able to set failure or success before even a
future is given to the user, but that doesn't mean we need to fulfill
it right away.

Post by Davide Andreoli
https://promisesaplus.com/
2.2.4 onFulfilled or onRejected must not be called until the execution
context <https://es5.github.io/#x10.3> stack contains only platform code
This point (as explained better on the site) means that "instant
resolution" is forbidden in JS.
I know we discussed this already, but it's a point that still scare me and
I fully understand why it is forbidden in JS. From a user perspective pov
having to think at both possible code flow that we are allowing (promise
callback called NOW, in the middle of the code where you define them, or
callback called later) can be really difficult to get right and error prone.

I like this point and it makes a lot of sense. So yes, I am for
delaying the resolution.

Post by Davide Andreoli
Also if we go to an "always async resolution" approach we can probably
remove lots of complexity in the promise implementation and in the promise
API.

Not really, it will be slightly more complex as we really need to keep
the behavior of being able to set success/failure right away (useful
for transitionning and cache implementation).

Post by Davide Andreoli
So what do you think? really we need this double-possible-behaviour in our
promise implementation?

I think it is a good idea, pretty straight forward to implement. It
will mean we do not need to ref/unref for reusing the same future for
multiple callback. The main issue is that you absolutely need a main
loop to implement this behavior (Not a problem from my point of view).
It will be easy to implement and will simplify API use.

[Carsten Haitzler (The Rasterman)]

Post by Cedric BAIL
Hi,

Post by Davide Andreoli
I'm starting this new thread to further discuss promises, thus the tag
[YetAnotherPromiseThread] :)

:-)

Post by Davide Andreoli
It seems to me we are putting too much ideas/discussion in the other
threads in a so sparse way that is starting to be difficult to follow the
discussions and to understand when we found some agreement, so please try
to don't go off-topic in this one.
The topic here is: do we really want to allow instant resolution of
promises?
For "instant resolution" I mean a promise that will call the user callbacks
as soon as the callbacks are "connected", thus in the middle of the user
code. (we took as an example a cached promise value)

What we want is to be able to set failure or success before even a
future is given to the user, but that doesn't mean we need to fulfill
it right away.

Post by Davide Andreoli
https://promisesaplus.com/
2.2.4 onFulfilled or onRejected must not be called until the execution
context <https://es5.github.io/#x10.3> stack contains only platform code
This point (as explained better on the site) means that "instant
resolution" is forbidden in JS.
I know we discussed this already, but it's a point that still scare me and
I fully understand why it is forbidden in JS. From a user perspective pov
having to think at both possible code flow that we are allowing (promise
callback called NOW, in the middle of the code where you define them, or
callback called later) can be really difficult to get right and error prone.

I like this point and it makes a lot of sense. So yes, I am for
delaying the resolution.

Post by Davide Andreoli
Also if we go to an "always async resolution" approach we can probably
remove lots of complexity in the promise implementation and in the promise
API.

Not really, it will be slightly more complex as we really need to keep
the behavior of being able to set success/failure right away (useful
for transitionning and cache implementation).

yes. you need to be able to SEt success/failure immediately, but you need to
defer the CALL that propagates the result to the user of the api. that does
require some code/work.

Post by Cedric BAIL

Post by Davide Andreoli
So what do you think? really we need this double-possible-behaviour in our
promise implementation?

I think it is a good idea, pretty straight forward to implement. It
will mean we do not need to ref/unref for reusing the same future for
multiple callback. The main issue is that you absolutely need a main
loop to implement this behavior (Not a problem from my point of view).
It will be easy to implement and will simplify API use.

i'm ok with needing a mainloop. we're centered on that design anyway. in fact
assuming a loop in eo opens up so many doors like eo being able to manage caches
within a loop cycle (eg keep some trash around in case it needs re-use or just
to defer deletion/destruction, and then nuke it when the loop goes idle and is
going to sleep - at least it defers that overhead until after a frame has been
rendered thus hopefully reducing latency a bit ... for example).

i can see how we do have to kind of blur the lines between eo and the loop. as
i said before - trying to avoid this is like what i tried to do with evas (make
it loop agnostic and avoid knowing about such things so it could be used in
multiple toolkits - that never happened and evas has been hurt by that design
decision). i think the same applies to eo here.

[Carsten Haitzler (The Rasterman)]

Post by Davide Andreoli
I'm starting this new thread to further discuss promises, thus the tag
[YetAnotherPromiseThread] :)
It seems to me we are putting too much ideas/discussion in the other
threads in a so sparse way that is starting to be difficult to follow the
discussions and to understand when we found some agreement, so please try
to don't go off-topic in this one.
The topic here is: do we really want to allow instant resolution of
promises?
For "instant resolution" I mean a promise that will call the user callbacks
as soon as the callbacks are "connected", thus in the middle of the user
code. (we took as an example a cached promise value)
https://promisesaplus.com/
2.2.4 onFulfilled or onRejected must not be called until the execution
context <https://es5.github.io/#x10.3> stack contains only platform code
This point (as explained better on the site) means that "instant
resolution" is forbidden in JS.

i actually agree with this. instant resolution causes problems. deferring it
until later even if the result is available now, but using something like a job
to do it is going to be much easier to work with from the api users point of
view. then the promise calls always get called later where you'd expect them to
be (and if the resolution Is instantly possible it's just later within the same
loop run).

also if we were to do instant resolution we would break this above js rule in
our js bindings because we would drive the promise callbacks where they should
not be. no matter the async solution we have i think this is a good rule to
follow.

Post by Davide Andreoli
I know we discussed this already, but it's a point that still scare me and
I fully understand why it is forbidden in JS. From a user perspective pov
having to think at both possible code flow that we are allowing (promise
callback called NOW, in the middle of the code where you define them, or
callback called later) can be really difficult to get right and error prone.
Also if we go to an "always async resolution" approach we can probably
remove lots of complexity in the promise implementation and in the promise
API.
So what do you think? really we need this double-possible-behaviour in our
promise implementation?

as above. the es5 rule is right. always defer even if result is known now.

Post by Davide Andreoli
------------------------------------------------------------------------------
_______________________________________________
enlightenment-devel mailing list
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel