On Mon, 18 Dec 2017 20:16:49 +0900 Jean-Philippe André <j...@videolan.org> said:
> On Sat, Dec 16, 2017 at 12:20 PM, Carsten Haitzler <ras...@rasterman.com> > wrote: > > > On Fri, 15 Dec 2017 14:29:22 -0500 Cedric Bail <ced...@ddlm.me> said: > > > > > > -------- 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. > > > > oh i know. i'm more thinking about spawning new threads+loops ... and > > should > > they be spawned by passing argv/c to them like processes get. it'd make all > > threads/loops consistent in this way. yes. being able to attach a void * > > might > > also be useful as this is what pthread will do anyway. > > > > > 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. > > > > well ecore_thread also does a thread pool, work queue etc. and it's > > asymmetric. > > you can create work thread items and then send back results, but once > > created > > you cant "send more work to the thread". you create more threads. > > > > i was thinking more along the lines of: > > > > we create a thread+loop via eo (you get back a LOCAL object handle > > representing > > the remote thread that you use to communicate with it), and now you can > > send > > stuff to it, and get back events from it (sending likely just returns you a > > future if you are expecting a reply so you can turn it into a > > "conversation" > > via promises/futures). this is what i mean by "ecore thread" needs doing. > > we > > need a way of creating threads and talking to them nicely. > > > > > > 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. > > > > that doesn't change the fact that destruction is expensive and generally > > pointless. there may b e some cases where it's nice. like "detecting leaks > > by > > looking at what is still allocated on exit" which frankly doesn't work too > > well > > anyway. but i found problems in eldbus for example when finally everything > > was > > really children of the loop object and destroying the loop object had > > issues > > that spider out everywhere. i was chasing one thing after the other in the > > tests there and decided for now just to not delete the loop object so i can > > move on. > > > > I disagree. If you want your app to exit quickly just call exit(0) and be > done with it. That should actually just be the default path pretty much (well finish off this loop cycle, exit it then exit app immediately). > Clean shutdown seems to me like a big plus for anything that pretends to > call itself a library. It helps in various scenarios, like valgrind, GDB > inside make check, etc... I know I personally rely on it quite a lot when > make check fails. i know even glibc doesn't clean up everything after itself... if libc doesn't... should we even bother? :) > I pushed a series of patches fixing most of this shutdown cycle. But most > of the ecore event types are stored as static variables and aren't properly > re-initialized after re-init. This breaks behavior with legacy where the > event handlers table simply didn't change after shutdown/init. Not sure if > all the event types should be reset (after flush) or if we should keep a > static table for legacy ecore event. that is indeed a good question. it brings up the following point: when i designed the ecore event types and ecore init/shutdown the intent was this: 1. an app/process does an ecore_init ONCE EVER. 2. it gets an event ONCE EVER 3. it only does ecore_shutdown ONCE EVER just before actually exiting. doing shutdown, then init, then shutdown, then init was not ever intended to work. you can tell by the api like you mention that it probably wasn't. but many of our tests try and do this and we have to jump through hoops to make it work. that is actually why i had to disable deletion of the loop object on shutdown (from memory). because disable forking in check and... it will do this again and again and caused issues with eldbus for sure. > > > <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 ? > > > > well they generally shouldn't be called, but they are really methods on the > > object, so i put them there. other than totally hiding them from eo ... i > > don't > > think we have a good solution yet. nothing like "@dangerous" or > > "@privileged" > > or something... just @protected which is not what i want really... i think. > > > > Basically should be @beta at least. Or indeed not exposed in EO. for now can i sit on the fence for this? it's really a simple "expose or tag appropriately" issue. > > message_handler_get was a class func due to a long talk i had with jpeg > > about > > making something that comes out nicely in bindings with typesafety and no > > casting. right now i forgot the detail... @jpeg - help me out - what was > > the > > detail again? ummm... I think it was that you can > > The idea was that the event info would be a subclass of the main event info > class, i.e. Efl.Loop.Message. > There are no subclasses yet, as none of the existing events can be > transformed to EO objects without extra wrapping for legacy. actually the "legacy ecore event" stuff does subclass the legacy events... but it's not exposed outside of efl's internal build. :) > So let's say our event info class is My_Message, subclass of > Efl.Loop.Message. > The idea I think was that you'd also subclass Efl.Loop.Message.Handler and > create a new event type there, which could then be strongly typed with > My_Message as event info type. message_call would be a trivial > implementation that figures out the eo event type (let's say with a > @protected method message_type returning Efl.Event.Description) and fires > it. but we could do that without a class function... there was a reason a class function solved it. with a normal method or a class func it'd be the same: My_Msg_Hnd_Class my_msgh = (My_Msg_Hnd_Class)loop.message_handler_get(My_Msg_Hnd_Class); my_msgh.event_callback_my_msg_event_add(...); vs: My_Msg_Hnd_Class my_msgh = (My_Msg_Hnd_Class)ef_loop_message_handler_get(loop, My_Msg_Hnd_Class); my_msgh.event_callback_my_msg_event_add(...); we're always going to return the more generic parent class handler type, so a cast would be needed there to the more specific type... but after that you get correct typing... argh. i can't remember now. it looks to me that it should just be a normal loop method as both ways above require a cast... but i know the reason was to not cast... > Honestly I'm not sure I remember right, and I'm not sure it's necessary > either :) This was just a lunch discussion after all :) well i remember i was struggling on what do do here to try and avoid casting (in c++ and similar langs. c/js/lua won't care). and the solution was "a class function" and it made perfect sense at the time and solved it... which it seemingly hasn't done... argh... > > > How is Efl.Loop.Handler suppose to be used ? How does it fit with Efl.Io > > > interfaces ? > > > > loop handler doesn't DO io. it also isn't limited to fd's. its the old fd > > handler AND win32 handler combined in one object. it calls event callbacks > > when > > the fd or win32 handle is ready for read/write etc. - then you do it. yes. > > fd's > > are low level as are win32 handles. this is probably generally useless for > > js/lua/c# etc. etc. .. but it's necessary for c/c++ and other native > > languages > > where these types exist and need to be integrated. this backs the legacy > > fd and > > win32 handlers now (they sit on top of it). the efl io stuff didn't > > integrate > > into the loop. they didn't register for wakeup with select and friends. the > > handlers are the glue to do this with and they handle the lower level > > objects > > (fd's, win32 handles). > > > > > 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 > > > > > > > > > -- > > ------------- 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 > > > > > > > -- > Jean-Philippe André > ------------------------------------------------------------------------------ > 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
