> -------- Original Message -------- > Subject: [E-devel] ecore / efl loop work > Local Time: December 14, 2017 9:30 PM > UTC Time: December 15, 2017 5:30 AM > From: ras...@rasterman.com > To: e <enlightenment-devel@lists.sourceforge.net>
<snip> > 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. ecore_app and argv/argc are already passed to the EFL_LOOP_EVENT_ARGUMENTS as parameter to the main loop. There is no real need I think to have that more exposed. As for Ecore_Thread, the only binding that could make use of it is C++ and it requires to definitively have a way to mark a function in .eo for other binding to ignore. At this point, there is no rush into implementing it. > 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. This is going to likely create problem. If you have for example added data to the loop object and you expect the destruction callback to be called at some point, well, that will be out of luck. I can't remember why, but the two tests you disable where from a real life case that required that behavior. So it would be best if I could remember, but right now, I feel like not destroying this object is ging to create trouble in the future as it will be one object that doesn't have the same behavior as every other one. <snip> > 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. I am not to sure of the various API around message. It is missing a lot of documentation to understand it, but in efl_loop, shouldn't message_process and message_exists only be internal function ? Or do you see any use for them in an application ? Why is message_handler_get an class function ? How is Efl.Loop.Handler suppose to be used ? How does it fit with Efl.Io interfaces ? Cedric ------------------------------------------------------------------------------ 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
