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 <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.
> 

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&id=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
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to