Re: [E-devel] [RFC] What to do with event registered during there own execution
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
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
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
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&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 > >
Re: [E-devel] [RFC] What to do with event registered during there own execution
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&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
Re: [E-devel] [RFC] What to do with event registered during there own execution
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
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