On Mon, 08 Jan 2018 13:49:33 -0500 Cedric Bail <[email protected]> said:
> > -------- 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: [email protected] > > To: Enlightenment developer list <[email protected]> > > [email protected] > > > > On Fri, 5 Jan 2018 10:53:46 -0200 Gustavo Sverzut Barbieri > > [email protected] said: > > > >> On Fri, Jan 5, 2018 at 4:04 AM, Carsten Haitzler [email protected] > >> wrote: > >> > >>> raster pushed a commit to branch master. > >>> http://git.enlightenment.org/core/efl.git/commit/?id=76b837002eaea56b5ecb174bffe284012084dc74 > >>> commit 76b837002eaea56b5ecb174bffe284012084dc74 > >>> Author: Carsten Haitzler (Rasterman) [email protected] > >>> 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. but then we have an ugly "jump into legacy" to do this even if you may have ported your app to eo/ionterfaces. that's why i made a wrapper just to make it conistent. it makes porting your app from legacy to eo/interfaces much easier (and when we drop legacy api your app will be fine). you don't have to restructure this kind of code. that's why i think it's good to have just from a practicality point of view. > 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 in this case bindings would have to manually deal with this. at least that makes sense to me. > 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. then porting an app gets harder... does it not? > ------------------------------------------------------------------------------ > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - [email protected] ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
