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 <cedric.b...@free.fr> 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? hmmmm.... 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

Reply via email to