On Fri, 22 Dec 2017 11:58:37 -0500 Cedric Bail <ced...@ddlm.me> said:
> > -------- Original Message -------- > > Subject: Re: [E-devel] ecore / efl loop work > > Local Time: December 20, 2017 5:30 PM > > UTC Time: December 21, 2017 1:30 AM > > From: ras...@rasterman.com > > To: Andrew Williams <a...@andywilliams.me> > > Enlightenment developer list <enlightenment-devel@lists.sourceforge.net> > > > > On Wed, 20 Dec 2017 18:36:30 +0000 Andrew Williams a...@andywilliams.me > > said: > > > >> Since this came in the core_loop example is no longer working correctly. > >> https://git.enlightenment.org/tools/examples.git/tree/reference/c/core/src/core_event.c > >> There are a few ERR about timers being dead and objects having parents that > >> didn't happen before. > >> Additionally a EFL_LOOP child of mainloop is created and a timer attached. > >> The timer no longer gets the TIMER_EVENT_TICK callback. > >> Any hints as to where I should start looking to see what is broken? > >> > >> woooo... creating a loop that is a child of another loop in the same > >> thread... sounds totally wrong. 1 loop per thread. at least for the legacy > >> ecore calls - they will try and work on the mainloop singleton not the > >> extra created loop. you COULD do this as long as everything is either in > >> one loop object or the other cleanly. > > It was actually done on purpose and I fixed a few bugs related to this once it obviously was assuming the mistake that the 2 loops share the same internals. just look at _events_freeze() before the changes to remove the "child loop". it created the loop and added an "POLL_HIGH" event callback to it... but it then never ran that loop. all it did was freeze and thaw it and never ran it, thus the _fast_cb callabcks should never be called... BUT by accident they would have been because before they would have shared the internal globals. it's obviously a mistake and it happened to "do things" because of the previous implementation. it certainly SHOULD not have called those _fast_cb pollers at all. this is exactly why the main loop has to become a real object. because mistakes will be made assuming design which is not there - it certainly was never intended to work. > in. The logic is that it does allow for having multiple application running > in the same process. I was thinking of using that for embedded multi > application using JS runtime. It would have provided clean enough isolation > between each runtime. they would need to share the same loop object then, or live in different threads. creating a new loop object would NOT have it share internals (fd handlers, timers, event queue etc.) and thus the 2nd loop certainly would not iterate (go over its event queue, select/listen to fd's etc.) UNLESS you run that loop. well that'd be the "obvious design". if you want to have loops magically work with nesting then the loop objects need to know about possible parent loop objects and somehow glue themselves into the parent loop object so when the parent runs the child "runs" too. but that was never the intent of a loop object. the intent was to have them per thread (1 per thread) and you know this has been discussed many times in this way. > <snip> > > >> but putting a loop as a child of a loop is going to be a nasty proposition > >> as a lot of the logic wants to walk back to the root object to find the > >> loop. if it finds another loop along the way... what do we do? i never > >> really looked into that or tested it. and indeed some objects may have > >> parents they didn't have before. this seems to be a bit of a pervasive > >> issue at some lower levels and in corners of efl that need to be ironed > >> out before we can call our api or design stable or even close. > > They stop on the first loop they find and it is exactly what we are looking they may but if the child loop asks for its loop provider .. it will get itself and not the parent. this is where things get a bit nasty. also when you run the child loop... what about fd's and timers and stuff in the parent loop? if you run the parent loop - what about the child? this is certainly not something we talked about having work. a loop per thread - yes. multiple loops per thread with nesting? no. and so this is a new assumption you are bringing in that wasn't designed for or expected. > for as a behavior here. You create your Efl.Ui.Win by parenting it to the > loop you are given. It being a subloop or something else doesn't really > matter as a loop object provide you with the needed feature fir Efl.Ui.Win to > work. it does matter because if you dont RUN the child loop... then the parent runs and the child loops' timers and what not will never time out because the parent loops knows nothing about the child loop object's content. see above. i don't think nesting loops is a good idea here. it's going to have the same nasties as nesting loop runs of the same loop that we've advised against doing for years. if you have a child loop then logically running it should do something sensible (like run it ignoring all stuff in the parent loop object). what is the real benefit of nesting loops? "merging apps" i just don't see as one. you dont need nested loops to build an app out of "what looks like multiple apps" where every app just inits itself and runs from the same loop. > Cedric > ------------------------------------------------------------------------------ > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- 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
