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 ? 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
