Oh my this loop/thread thing is a mess. I practically got ripped a new one on a different thread because I assumed that the main loop would be a useful thing to access. And now we have explicit access to the main loop. Which main? Which thread?
Can we please step back for a minute and actually agree what the loop model is intended to be so we can all be working in the same direction? Thanks, Andy On Mon, 8 Jan 2018 at 10:49, Cedric Bail <ced...@ddlm.me> wrote: > > -------- Original Message -------- > > Subject: Re: [E-devel] [EGIT] [core/efl] master 01/01: efl loop - > provide efl namespace versions of begin/end locks on mainloop > > Local Time: January 5, 2018 5:04 AM > > UTC Time: January 5, 2018 1:04 PM > > From: ras...@rasterman.com > > To: Enlightenment developer list < > enlightenment-devel@lists.sourceforge.net> > > g...@lists.enlightenment.org > > > > On Fri, 5 Jan 2018 10:53:46 -0200 Gustavo Sverzut Barbieri > barbi...@gmail.com > > said: > > > >> On Fri, Jan 5, 2018 at 4:04 AM, Carsten Haitzler ras...@rasterman.com > wrote: > >> > >>> raster pushed a commit to branch master. > >>> > http://git.enlightenment.org/core/efl.git/commit/?id=76b837002eaea56b5ecb174bffe284012084dc74 > >>> commit 76b837002eaea56b5ecb174bffe284012084dc74 > >>> Author: Carsten Haitzler (Rasterman) ras...@rasterman.com > >>> Date: Fri Jan 5 15:01:02 2018 +0900 > > <snip> > > > we can't do this multi-loop because this is also tied specifically to > switching > > eo domain id's from "thread" to "main" and back. main has one and only > one > > instance - the mainloop eo id. thread is a thread-local per thread > domain so > > you can't actually switch to another thread's domain ... except the main > loop. > > I still do strongly believe that this is a problem that needs solving, but > anyway, there is no point into moving function like that in the new unified > namespace at the moment as we can always use legacy along with the new API. > Also as there is a lot of problems with bindings regarding threads to be > solved and have eolian properly aware of that. So it is a C only API at the > moment. Which reinforce my point of just use legacy API for this purpose. > Also it is clearly not a priority and not something we should start pushing > for a release. For this reasons and Gustavo arguments, I think we should > remove this added function and only rely on legacy for the time being. > > ------------------------------------------------------------------------------ > 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 > -- http://andywilliams.me http://ajwillia.ms ------------------------------------------------------------------------------ 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
