Events were processed before init for a example, evas events, move, resize, etc. I'm not the user but this kind of response seems very inresponsible for users once the versioning out.
On Thu, Jul 25, 2019 at 10:01 PM Mike Blumenkrantz < michael.blumenkra...@gmail.com> wrote: > Hi, > > On Thu, Jul 25, 2019 at 4:15 AM Hermet Park <hermetp...@gmail.com> wrote: > > > I remember you modified the behavior of the init count not to go down 0. > > That might bring this additional patch. > > > > I'm not sure what this means? > > > > > > The problem is, these changes breaks the compatibility. > > Even I think the original behavior would better than this in user pov. > > > > Let me explain a scenario. > > > > Before main loop begin, > > User might add A event with callback (A_CB) in intialize step. > > But user have no any guarantee when A_CB would be called, but they'd like > > to do something there, even they try quit the process based on some > > conditions (maybe exception case or a corner case possible) > > > > Actually, this A_CB could be called before mainloop begin, and now the > > process won't be quited because quit request would be ignored. > > > > Before these changes, > > the process could be exited(?) successfully because the mainloop won't > > started at this scenario. *quit (count = - 1) -> *begin (count = 0) > > and now this breaks the behavior and user should take care of the loop > > condition when they handle this in event callbacks. > > > > The case you're describing sounds like a bug. In fact, it is directly in > opposition to the function's documentation, which explicitly states that > "all events currently on the queue" will still be processed prior to > quitting the main loop. Prior to this patch, no events were processed, > which is clearly not how main loops should work. > > The fact that this behavior existed was nothing more than an untested > corner case. We actually had unit tests which were failing intermittently > because they unintentionally triggered this codepath. > > If you have cases where this bug is being triggered, you'll want to update > them. > > > Regards, > Mike > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Jul 22, 2019 at 9:42 PM Mike Blumenkrantz < > > michael.blumenkra...@gmail.com> wrote: > > > > > cedric pushed a commit to branch master. > > > > > > > > > > > > http://git.enlightenment.org/core/efl.git/commit/?id=17f433c57bfa11319a22fde1aedb21e99a3a1268 > > > > > > commit 17f433c57bfa11319a22fde1aedb21e99a3a1268 > > > Author: Mike Blumenkrantz <zm...@samsung.com> > > > Date: Fri Jul 19 15:42:09 2019 -0400 > > > > > > ecore: avoid breaking next main loop start if quit occurs outside > of > > > loop > > > > > > in the case where ecore_main_loop_quit() was called before > > > ecore_main_loop_begin(), > > > the latter call would exit immediately without ever iterating the > > main > > > loop > > > > > > @fix > > > > > > Reviewed-by: Cedric BAIL <cedric.b...@free.fr> > > > Differential Revision: https://phab.enlightenment.org/D9360 > > > --- > > > src/lib/ecore/ecore_main.c | 3 +++ > > > src/lib/ecore/ecore_private.h | 1 + > > > 2 files changed, 4 insertions(+) > > > > > > diff --git a/src/lib/ecore/ecore_main.c b/src/lib/ecore/ecore_main.c > > > index 523add2af3..f7d248fc27 100644 > > > --- a/src/lib/ecore/ecore_main.c > > > +++ b/src/lib/ecore/ecore_main.c > > > @@ -1177,6 +1177,7 @@ _ecore_main_loop_iterate_may_block(Eo *obj, > > > Efl_Loop_Data *pd, int may_block) > > > void > > > _ecore_main_loop_begin(Eo *obj, Efl_Loop_Data *pd) > > > { > > > + pd->loop_active++; > > > if (obj == ML_OBJ) > > > { > > > #ifdef HAVE_SYSTEMD > > > @@ -1240,11 +1241,13 @@ _ecore_main_loop_begin(Eo *obj, Efl_Loop_Data > > *pd) > > > pd->do_quit = 0; > > > #endif > > > } > > > + pd->loop_active--; > > > } > > > > > > void > > > _ecore_main_loop_quit(Eo *obj, Efl_Loop_Data *pd) > > > { > > > + if (!pd->loop_active) return; > > > pd->do_quit = 1; > > > if (obj != ML_OBJ) return; > > > #ifdef USE_G_MAIN_LOOP > > > diff --git a/src/lib/ecore/ecore_private.h > > b/src/lib/ecore/ecore_private.h > > > index b66b50915d..99a3fb7740 100644 > > > --- a/src/lib/ecore/ecore_private.h > > > +++ b/src/lib/ecore/ecore_private.h > > > @@ -163,6 +163,7 @@ struct _Efl_Loop_Data > > > > > > int idlers; > > > int in_loop; > > > + unsigned int loop_active; > > > > > > struct { > > > int high; > > > > > > -- > > > > > > > > > > > > > -- > > Regards, Hermet > > > > _______________________________________________ > > 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 > -- Regards, Hermet _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
