On Fri, 15 Dec 2017 07:07:53 +0100 Vincent Torri <vincent.to...@gmail.com> said:
> On Fri, Dec 15, 2017 at 6:30 AM, Carsten Haitzler <ras...@rasterman.com> > wrote: > > I've been working on this for a while and now have things in a pretty good > > state. I just pushed a commit that does a huge amount of this (not all - see > > 5dd52fd09b7d79c70b3134423a87aa6400a2d994). But it's a huge step to efl loop > > objects really being self contained. > > > > efl loop fd didn't handle windows so i put in efl loop handlers that handle > > both fd's, file fd's and win32 handles. > > i would like to use on win32 handlers on Windows (so no select() API > usage). Maybe that could simplify a bit ? ? i'm not sure what you mean/ the efl loop handler allows for fds, (socket, file) AND for win32 handles. the handler can listen to any one of these 3.... it's there.it's the api. the implementation is the same as before. > Vincent > > > maybe the loop fd's should go as they are a > > bit more limited? i've added a replacement for the ecore event system using > > classes and handler objects for event types etc. > > > > there are internals that need some cleaning up like internal use of > > ecore_timer, ecore_idler. need to decide what to do with ecore_app and > > argv/argc stuff. the ecore signal code needs some cleaning up internally > > too. ecore_thread and ecore_pipe need re-implementation for > > inter-thread/loop messaging/calling etc. > > > > i also don't delete the loop object on ecore shutdown. it's ... problematic. > > tbh the whole "shutdown" stuff we have in efl is just not worth the corner > > case work. init and leave up and running for the life of the process. it's > > simpler and it also actually makes it faster to exit an app... shutting > > down actually takes a lot of work. i've seen it delay an app closing a lot. > > > > i've been using this code for a few weeks now on everything. i've checked > > for leaks. i've made "make check" work. i had to disable some tests that are > > assuming a lifecycle of objects deleted by main loop object etc. because of > > the above (don't delete loop object). > > > > this api is NOT FINAL. it's a good first stab at doing all of this work. it > > could probably improve. i need to clear up some of the internal bits that > > still use single mainloop dependent calls as per the commit and above, and > > some other things need a design and implementation... and then actually > > create multiple threads with loops and even decide HOW threads and loops > > are created and spawned and hooked up etc. ... but this is a huge step > > there. > > > > -- > > ------------- 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 > > ------------------------------------------------------------------------------ > 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
