On Mon, 08 Jan 2018 19:21:29 +0000 Andrew Williams <[email protected]> said:
> 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? the main loop object is already gotten by a function call. it's a singleton by design in efl and we're not going to change that because almost all of efl is built on it. how you find your loop should be via your object tree though. that way for the parts of efl we allow to exist in other loops (evas, edje, elm etc. won't for sure, but efl.net ultimately should be able to, but currently it can't),, they will find their local loop, not main loop and work correctly. since eo objects are not thread safe (except for shared objects that come with a big performance caveat), they have been made thread local thus only accessible within their local thread. they use a tls (pthread_xxx_specific) to do this. so you can't access the loop object of another thread safely at all. ever. because of the above. so what you need is either a shared object (as above) or you need to have a thread local object that backs onto the other thread's objects and internally uses "ipc" at a lower level to do it. like pipe() creates 2 fd's (a read and a write). this would be similar. my idea is that to create threads you use an eo api to spawn a task (of the thread class) and that returns you a thread local object you can access. that object behind the scenes uses pipes/thread queues/whatever to communicate with the other thread. the other thread is created for you and like ecore_thread join()ing of that thread on exit will be handled for you, and the other thread will have a loop created like the EFL_MAIN does and you get launched right into your args() event callback for that loop. just like the main loop/process. when this thread wants to "talk back" by default the loop is bound to its parent thread (be it main loop or another loop/thread - like parent and child process and if you set up stdin/out as pipes to/from the parent process you can do i/o to/from it), and thus you can get data coming in from the parent task (thread... or even process) and send data back. it's al done with thread-local objects though. > 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 <[email protected]> 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: [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. > > 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 > > [email protected] > > 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 > [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
