On Thu, Dec 01, 2016 at 10:11:50AM +0100, [email protected] 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 <[email protected]> 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 > > > [email protected] > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) [email protected] > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > enlightenment-devel mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > ------------------------------------------------------------------------------ > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
