Re: [E-devel] [RFC] What to do with event registered during there own execution

[Gustavo Sverzut Barbieri]

On Fri, Dec 2, 2016 at 2:58 AM, Carsten Haitzler  wrote:
> On Thu, 1 Dec 2016 12:36:28 -0200 Gustavo Sverzut Barbieri 
> 
> said:
>
>> On Thu, Dec 1, 2016 at 6:33 AM, Carsten Haitzler  
>> wrote:
>> > On Wed, 30 Nov 2016 21:58:19 -0800 Cedric BAIL  said:
>> >
>> >> Hello,
>> >>
>> >> So we have currently a bug showing up for some people, that is
>> >> actually related to how we handle event when a callback is registered
>> >> from within a call triggered by that same event. There is a few
>> >> possible behavior :
>> >>
>> >> - Do not call the callback until the next time the event is triggered.
>> >> - If inserted before the currently executed callback, do not call, if
>> >> after do trigger the call.
>> >> - Trigger the call whatever the position of insertion (maybe even
>> >> trigger it right away if it was inserted before)
>> >>
>> >> I am leaning toward the first case, but I am not really sure this is a
>> >> good idea in all case. Any one with a good reason why we should do any
>> >> of the other possibility ?
>> >
>> > hmm. i think it's more complex than this. so some pseudocode:
>> >
>> > -> event_call(obj, ev1)
>> > ---> event_cb_add(obj, ev1)
>> >
>> > so what to do here? when the event cb is added to the
>> > end of the array should it be called again while event_call() is still
>> > calling.. in this case i'd say it shouldn't.
>> >
>> > now here comes the complex stuff:
>> >
>> > -> event_call(obj, ev1)
>> > ---> event_cb_add(obj, ev1)
>> > ---> event_call(obj, ev1)
>> >
>> > so now what? inside the 2nd event_call should we call the callback we just
>> > added before? yes. i'd say so... now combine with the 1st case above. ..
>> > what happens when we go back and return to the FIRST event_call. we called
>> > in the child event_call()... should we call in the parent? h i'd
>> > say no.
>> >
>> > how do we make this work AND make it efficient? but the above 2 cases are
>> > pretty much a core concept that would expand to all other cases up and down
>> > the stack. i agree that once you add an event that future event callback
>> > calls should trigger it... but only future event callback calls that are
>> > STARTED after the event cb add. not existing ones that are still "being
>> > processed".
>>
>> agreed this is the expected behavior, however pretty uncommon in real
>> life scenario to emit the event from the event callback of the same
>> object, after all if done naively this can trigger infinite recursion.
>
> even if uncommon... it's still something we have to handle. in fact this can
> happen as side-effects. like:
>
> on mouse enter...
>   move object
>   move of object indirectly causes a mouse out e.g. it shows an object on top
> mouse out handler raises original object
>   original object now gets a mouse in...
> ... repeat
>
> :) or things like this happen where feedback loops happen. often these 
> feedback
> lops are shortcut somehow and don't recurse forever it is does mean that you
> can have a mouse in called on an obj inside the mouse in and if you add/remove
> mouse in callbacks this can all be affected.
>
> either way we need a simple and consistent behaviour that works the same way
> all the time AND is "logical" and "makes sense". what this is about is... what
> makes sense?
>
> above is what i proposed makes sense to me... it seems to make sense to you.
> what about others...

Yes, I do agree with fixing it for once and for all, as you said these
cases will happen... and we must handle them. What I tried to say is
that our performance impact should be minimal on the usual case,
optimize for that. Marcel's solution seems to do it nicely (in text, I
did not check the patch).


-- 
Gustavo Sverzut Barbieri
--
Mobile: +55 (16) 99354-9890

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [RFC] What to do with event registered during there own execution

[The Rasterman]

On Thu, 1 Dec 2016 12:36:28 -0200 Gustavo Sverzut Barbieri 
said:

> On Thu, Dec 1, 2016 at 6:33 AM, Carsten Haitzler  wrote:
> > On Wed, 30 Nov 2016 21:58:19 -0800 Cedric BAIL  said:
> >
> >> Hello,
> >>
> >> So we have currently a bug showing up for some people, that is
> >> actually related to how we handle event when a callback is registered
> >> from within a call triggered by that same event. There is a few
> >> possible behavior :
> >>
> >> - Do not call the callback until the next time the event is triggered.
> >> - If inserted before the currently executed callback, do not call, if
> >> after do trigger the call.
> >> - Trigger the call whatever the position of insertion (maybe even
> >> trigger it right away if it was inserted before)
> >>
> >> I am leaning toward the first case, but I am not really sure this is a
> >> good idea in all case. Any one with a good reason why we should do any
> >> of the other possibility ?
> >
> > hmm. i think it's more complex than this. so some pseudocode:
> >
> > -> event_call(obj, ev1)
> > ---> event_cb_add(obj, ev1)
> >
> > so what to do here? when the event cb is added to the
> > end of the array should it be called again while event_call() is still
> > calling.. in this case i'd say it shouldn't.
> >
> > now here comes the complex stuff:
> >
> > -> event_call(obj, ev1)
> > ---> event_cb_add(obj, ev1)
> > ---> event_call(obj, ev1)
> >
> > so now what? inside the 2nd event_call should we call the callback we just
> > added before? yes. i'd say so... now combine with the 1st case above. ..
> > what happens when we go back and return to the FIRST event_call. we called
> > in the child event_call()... should we call in the parent? h i'd
> > say no.
> >
> > how do we make this work AND make it efficient? but the above 2 cases are
> > pretty much a core concept that would expand to all other cases up and down
> > the stack. i agree that once you add an event that future event callback
> > calls should trigger it... but only future event callback calls that are
> > STARTED after the event cb add. not existing ones that are still "being
> > processed".
> 
> agreed this is the expected behavior, however pretty uncommon in real
> life scenario to emit the event from the event callback of the same
> object, after all if done naively this can trigger infinite recursion.

even if uncommon... it's still something we have to handle. in fact this can
happen as side-effects. like:

on mouse enter...
  move object
  move of object indirectly causes a mouse out e.g. it shows an object on top
mouse out handler raises original object
  original object now gets a mouse in...
... repeat

:) or things like this happen where feedback loops happen. often these feedback
lops are shortcut somehow and don't recurse forever it is does mean that you
can have a mouse in called on an obj inside the mouse in and if you add/remove
mouse in callbacks this can all be affected.

either way we need a simple and consistent behaviour that works the same way
all the time AND is "logical" and "makes sense". what this is about is... what
makes sense?

above is what i proposed makes sense to me... it seems to make sense to you.
what about others...


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [RFC] What to do with event registered during there own execution

[Gustavo Sverzut Barbieri]

On Thu, Dec 1, 2016 at 6:33 AM, Carsten Haitzler  wrote:
> On Wed, 30 Nov 2016 21:58:19 -0800 Cedric BAIL  said:
>
>> Hello,
>>
>> So we have currently a bug showing up for some people, that is
>> actually related to how we handle event when a callback is registered
>> from within a call triggered by that same event. There is a few
>> possible behavior :
>>
>> - Do not call the callback until the next time the event is triggered.
>> - If inserted before the currently executed callback, do not call, if
>> after do trigger the call.
>> - Trigger the call whatever the position of insertion (maybe even
>> trigger it right away if it was inserted before)
>>
>> I am leaning toward the first case, but I am not really sure this is a
>> good idea in all case. Any one with a good reason why we should do any
>> of the other possibility ?
>
> hmm. i think it's more complex than this. so some pseudocode:
>
> -> event_call(obj, ev1)
> ---> event_cb_add(obj, ev1)
>
> so what to do here? when the event cb is added to the
> end of the array should it be called again while event_call() is still
> calling.. in this case i'd say it shouldn't.
>
> now here comes the complex stuff:
>
> -> event_call(obj, ev1)
> ---> event_cb_add(obj, ev1)
> ---> event_call(obj, ev1)
>
> so now what? inside the 2nd event_call should we call the callback we just
> added before? yes. i'd say so... now combine with the 1st case above. .. what
> happens when we go back and return to the FIRST event_call. we called in the
> child event_call()... should we call in the parent? h i'd say no.
>
> how do we make this work AND make it efficient? but the above 2 cases are
> pretty much a core concept that would expand to all other cases up and down 
> the
> stack. i agree that once you add an event that future event callback calls
> should trigger it... but only future event callback calls that are STARTED
> after the event cb add. not existing ones that are still "being processed".

agreed this is the expected behavior, however pretty uncommon in real
life scenario to emit the event from the event callback of the same
object, after all if done naively this can trigger infinite recursion.

-- 
Gustavo Sverzut Barbieri
--
Mobile: +55 (16) 99354-9890

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [RFC] What to do with event registered during there own execution

[Al Poole]

I'm not sure how relative this is, however with a clean tree and the latest
E patches the issue remains.

This commit:
https://git.enlightenment.org/core/enlightenment.git/commit/?id=8934ada4d8d9576e270defda5877589abdd2345d

Does NOT fix the issue for me here.

On Thu, Dec 1, 2016 at 12:01 PM,  wrote:

> On Thu, Dec 01, 2016 at 10:11:50AM +0100, marcel-hollerb...@t-online.de
> wrote:
> > Hello,
> >
> > On Thu, Dec 01, 2016 at 05:33:10PM +0900, Carsten Haitzler wrote:
> > > On Wed, 30 Nov 2016 21:58:19 -0800 Cedric BAIL 
> said:
> > >
> > > > Hello,
> > > >
> > > > So we have currently a bug showing up for some people, that is
> > > > actually related to how we handle event when a callback is registered
> > > > from within a call triggered by that same event. There is a few
> > > > possible behavior :
> > > >
> > > > - Do not call the callback until the next time the event is
> triggered.
> > > > - If inserted before the currently executed callback, do not call, if
> > > > after do trigger the call.
> > > > - Trigger the call whatever the position of insertion (maybe even
> > > > trigger it right away if it was inserted before)
> > > >
> > > > I am leaning toward the first case, but I am not really sure this is
> a
> > > > good idea in all case. Any one with a good reason why we should do
> any
> > > > of the other possibility ?
> > >
> > > hmm. i think it's more complex than this. so some pseudocode:
> > >
> > > -> event_call(obj, ev1)
> > > ---> event_cb_add(obj, ev1)
> > >
> > > so what to do here? when the event cb is added to the
> > > end of the array should it be called again while event_call() is still
> > > calling.. in this case i'd say it shouldn't.
> > >
> > > now here comes the complex stuff:
> > >
> > > -> event_call(obj, ev1)
> > > ---> event_cb_add(obj, ev1)
> > > ---> event_call(obj, ev1)
> > >
> > > so now what? inside the 2nd event_call should we call the callback we
> just
> > > added before? yes. i'd say so... now combine with the 1st case above.
> .. what
> > > happens when we go back and return to the FIRST event_call. we called
> in the
> > > child event_call()... should we call in the parent? h i'd say
> no.
> > >
> > > how do we make this work AND make it efficient? but the above 2 cases
> are
> > > pretty much a core concept that would expand to all other cases up and
> down the
> > > stack. i agree that once you add an event that future event callback
> calls
> > > should trigger it... but only future event callback calls that are
> STARTED
> > > after the event cb add. not existing ones that are still "being
> processed".
> >
> > in https://git.enlightenment.org/core/efl.git/log/?h=devs/
> bu5hm4n/failing_eo_test
> > (Which also fixes the bug regarding the problem named above)
> >
> > is a solution to get a stack like data structure to attach event
> > emission informations to a event_callback_call. With having this we
> > could add there some filed like "generation" if you start a new
> > event_callback_call in a other the generation is higher than the one
> > before.
> >
> > Now we can also add a callback number to each subscription (just like
> > the delete_me flag, and check in the for loop if the callback generation
> > is lower than the current generation. If yes execute it, if no ignore
> > it. After each callback_call a clean method is executed which sets the
> > generation to 0 so its executed all the time.
> >
> > I think this solution is pretty performant, you need O(1) to access the
> > most current frame, and there is no heap allocation at all. The only
> > more cost would be the cleanup to 0, which is expensive for big
> > subscription lists, but maybe this can also be optimized like
> > deletions_waiting.
> >
>
> Since code is easier to read as a proposal, here is a commit that
> implements what i meant. This implements the first option named by
> cedric.
>
> Commit:
> https://git.enlightenment.org/core/efl.git/commit/?h=devs/
> bu5hm4n/failing_eo_test=8bf82c451f2665e641832035bbc295a4d8c48c0b
>
> I dont see where this could hurt performance ... if you find a spot,
> tell me.
>
> > >
> > > discussion points?
> > >
> > > > Have fun,
> > > > --
> > > > Cedric BAIL
> > > >
> > > > 
> --
> > > > ___
> > > > enlightenment-devel mailing list
> > > > enlightenment-devel@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > > >
> > >
> > >
> > > --
> > > - Codito, ergo sum - "I code, therefore I am"
> --
> > > The Rasterman (Carsten Haitzler)ras...@rasterman.com
> > >
> > >
> > > 
> --
> > > ___
> > > enlightenment-devel mailing list
> > > enlightenment-devel@lists.sourceforge.net
> > > 

Re: [E-devel] [RFC] What to do with event registered during there own execution

[marcel-hollerbach]

On Thu, Dec 01, 2016 at 10:11:50AM +0100, marcel-hollerb...@t-online.de wrote:
> Hello,
> 
> On Thu, Dec 01, 2016 at 05:33:10PM +0900, Carsten Haitzler wrote:
> > On Wed, 30 Nov 2016 21:58:19 -0800 Cedric BAIL  said:
> > 
> > > Hello,
> > > 
> > > So we have currently a bug showing up for some people, that is
> > > actually related to how we handle event when a callback is registered
> > > from within a call triggered by that same event. There is a few
> > > possible behavior :
> > > 
> > > - Do not call the callback until the next time the event is triggered.
> > > - If inserted before the currently executed callback, do not call, if
> > > after do trigger the call.
> > > - Trigger the call whatever the position of insertion (maybe even
> > > trigger it right away if it was inserted before)
> > > 
> > > I am leaning toward the first case, but I am not really sure this is a
> > > good idea in all case. Any one with a good reason why we should do any
> > > of the other possibility ?
> > 
> > hmm. i think it's more complex than this. so some pseudocode:
> > 
> > -> event_call(obj, ev1)
> > ---> event_cb_add(obj, ev1)
> > 
> > so what to do here? when the event cb is added to the
> > end of the array should it be called again while event_call() is still
> > calling.. in this case i'd say it shouldn't.
> > 
> > now here comes the complex stuff:
> > 
> > -> event_call(obj, ev1)
> > ---> event_cb_add(obj, ev1)
> > ---> event_call(obj, ev1)
> > 
> > so now what? inside the 2nd event_call should we call the callback we just
> > added before? yes. i'd say so... now combine with the 1st case above. .. 
> > what
> > happens when we go back and return to the FIRST event_call. we called in the
> > child event_call()... should we call in the parent? h i'd say no.
> > 
> > how do we make this work AND make it efficient? but the above 2 cases are
> > pretty much a core concept that would expand to all other cases up and down 
> > the
> > stack. i agree that once you add an event that future event callback calls
> > should trigger it... but only future event callback calls that are STARTED
> > after the event cb add. not existing ones that are still "being processed".
> 
> in 
> https://git.enlightenment.org/core/efl.git/log/?h=devs/bu5hm4n/failing_eo_test
> (Which also fixes the bug regarding the problem named above)
> 
> is a solution to get a stack like data structure to attach event
> emission informations to a event_callback_call. With having this we
> could add there some filed like "generation" if you start a new
> event_callback_call in a other the generation is higher than the one
> before.
> 
> Now we can also add a callback number to each subscription (just like
> the delete_me flag, and check in the for loop if the callback generation
> is lower than the current generation. If yes execute it, if no ignore
> it. After each callback_call a clean method is executed which sets the
> generation to 0 so its executed all the time.
> 
> I think this solution is pretty performant, you need O(1) to access the
> most current frame, and there is no heap allocation at all. The only
> more cost would be the cleanup to 0, which is expensive for big
> subscription lists, but maybe this can also be optimized like
> deletions_waiting.
> 

Since code is easier to read as a proposal, here is a commit that
implements what i meant. This implements the first option named by
cedric.

Commit:
https://git.enlightenment.org/core/efl.git/commit/?h=devs/bu5hm4n/failing_eo_test=8bf82c451f2665e641832035bbc295a4d8c48c0b

I dont see where this could hurt performance ... if you find a spot,
tell me.

> > 
> > discussion points?
> > 
> > > Have fun,
> > > -- 
> > > Cedric BAIL
> > > 
> > > --
> > > ___
> > > enlightenment-devel mailing list
> > > enlightenment-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > > 
> > 
> > 
> > -- 
> > - Codito, ergo sum - "I code, therefore I am" --
> > The Rasterman (Carsten Haitzler)ras...@rasterman.com
> > 
> > 
> > --
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 
> --
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net

Re: [E-devel] [RFC] What to do with event registered during there own execution

[marcel-hollerbach]

Hello,

On Thu, Dec 01, 2016 at 05:33:10PM +0900, Carsten Haitzler wrote:
> On Wed, 30 Nov 2016 21:58:19 -0800 Cedric BAIL  said:
> 
> > Hello,
> > 
> > So we have currently a bug showing up for some people, that is
> > actually related to how we handle event when a callback is registered
> > from within a call triggered by that same event. There is a few
> > possible behavior :
> > 
> > - Do not call the callback until the next time the event is triggered.
> > - If inserted before the currently executed callback, do not call, if
> > after do trigger the call.
> > - Trigger the call whatever the position of insertion (maybe even
> > trigger it right away if it was inserted before)
> > 
> > I am leaning toward the first case, but I am not really sure this is a
> > good idea in all case. Any one with a good reason why we should do any
> > of the other possibility ?
> 
> hmm. i think it's more complex than this. so some pseudocode:
> 
> -> event_call(obj, ev1)
> ---> event_cb_add(obj, ev1)
> 
> so what to do here? when the event cb is added to the
> end of the array should it be called again while event_call() is still
> calling.. in this case i'd say it shouldn't.
> 
> now here comes the complex stuff:
> 
> -> event_call(obj, ev1)
> ---> event_cb_add(obj, ev1)
> ---> event_call(obj, ev1)
> 
> so now what? inside the 2nd event_call should we call the callback we just
> added before? yes. i'd say so... now combine with the 1st case above. .. what
> happens when we go back and return to the FIRST event_call. we called in the
> child event_call()... should we call in the parent? h i'd say no.
> 
> how do we make this work AND make it efficient? but the above 2 cases are
> pretty much a core concept that would expand to all other cases up and down 
> the
> stack. i agree that once you add an event that future event callback calls
> should trigger it... but only future event callback calls that are STARTED
> after the event cb add. not existing ones that are still "being processed".

in 
https://git.enlightenment.org/core/efl.git/log/?h=devs/bu5hm4n/failing_eo_test
(Which also fixes the bug regarding the problem named above)

is a solution to get a stack like data structure to attach event
emission informations to a event_callback_call. With having this we
could add there some filed like "generation" if you start a new
event_callback_call in a other the generation is higher than the one
before.

Now we can also add a callback number to each subscription (just like
the delete_me flag, and check in the for loop if the callback generation
is lower than the current generation. If yes execute it, if no ignore
it. After each callback_call a clean method is executed which sets the
generation to 0 so its executed all the time.

I think this solution is pretty performant, you need O(1) to access the
most current frame, and there is no heap allocation at all. The only
more cost would be the cleanup to 0, which is expensive for big
subscription lists, but maybe this can also be optimized like
deletions_waiting.

> 
> discussion points?
> 
> > Have fun,
> > -- 
> > Cedric BAIL
> > 
> > --
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > 
> 
> 
> -- 
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)ras...@rasterman.com
> 
> 
> --
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [RFC] What to do with event registered during there own execution

[The Rasterman]

On Wed, 30 Nov 2016 21:58:19 -0800 Cedric BAIL  said:

> Hello,
> 
> So we have currently a bug showing up for some people, that is
> actually related to how we handle event when a callback is registered
> from within a call triggered by that same event. There is a few
> possible behavior :
> 
> - Do not call the callback until the next time the event is triggered.
> - If inserted before the currently executed callback, do not call, if
> after do trigger the call.
> - Trigger the call whatever the position of insertion (maybe even
> trigger it right away if it was inserted before)
> 
> I am leaning toward the first case, but I am not really sure this is a
> good idea in all case. Any one with a good reason why we should do any
> of the other possibility ?

hmm. i think it's more complex than this. so some pseudocode:

-> event_call(obj, ev1)
---> event_cb_add(obj, ev1)

so what to do here? when the event cb is added to the
end of the array should it be called again while event_call() is still
calling.. in this case i'd say it shouldn't.

now here comes the complex stuff:

-> event_call(obj, ev1)
---> event_cb_add(obj, ev1)
---> event_call(obj, ev1)

so now what? inside the 2nd event_call should we call the callback we just
added before? yes. i'd say so... now combine with the 1st case above. .. what
happens when we go back and return to the FIRST event_call. we called in the
child event_call()... should we call in the parent? h i'd say no.

how do we make this work AND make it efficient? but the above 2 cases are
pretty much a core concept that would expand to all other cases up and down the
stack. i agree that once you add an event that future event callback calls
should trigger it... but only future event callback calls that are STARTED
after the event cb add. not existing ones that are still "being processed".

discussion points?

> Have fun,
> -- 
> Cedric BAIL
> 
> --
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel