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, <marcel-hollerb...@t-online.de> 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 <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 > ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
