On Thursday, July 25, 2019 10:43 PM, Hermet Park <hermetp...@gmail.com> wrote: > for your understanding, i showed you a very simplied example, >
> xxxx_cb()
> {
> ...
> elm_exit();
> }
>
> void test()
> {
> obj = elm_xxx_add();
> evas_object_smart_callback_add(obj, "xxxx," xxxx_cb, ...);
> }
>
> void main()
> {
> ...
> test();
> ...
> elm_run();
> ...
> }
>
> Nobody guarantees when this xxx_cb would be called, whether after runinng
> mainloop or before.
> If efl triggered this callbacks before mainloop, We can't leave this just
> to user issue.
> And possibly efl does.
I am a bit puzzle here by what event we are talking about. Efl will trigger
event that are queued inside the main loop. Evas event are typically not queued
themself. They can be a side effect of an Ecore event being triggered. Still in
the case considered, the issue is that the Ecore events are not generated and
the loop is not running as it should per documentation.
We are talking here of a edge effect that is actually triggering bugs in our
own code base. The likeliness of it triggering bugs in people using our API
would be a logical assumption. The question is then, is it a behavior worth
preserving (aka backward bug compatible) or not. I do think, considering that
ourself get the usage wrong unintentionally, it is likely users do too. I would
still expect them to be less impacted as not many write full test suite like we
do as this is the most likely scenario in which you would have an exit before
you run the main loop.
All in all, I think it is a reasonable change that kill a class of bugs hard to
detect otherwise.
Cedric
> On Fri, Jul 26, 2019 at 2:13 PM Hermet Park hermetp...@gmail.com wrote:
>
> > 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
>
> --
>
> Regards, Hermet
>
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
publickey - cedric@ddlm.me - 0x1869A77F.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
