On Wed, Dec 20, 2017 at 11:01 AM, Carsten Haitzler <ras...@rasterman.com> wrote:
> 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? :) > There is no explicit call to init glibc. So should we init our libs with _start or _dl_start? :) Shutdown could be used to optimize some memory usage (eg. elm when you don't need a UI anymore). I'm well aware that this is nothing more than an ideal... (eg. EO's classes aren't deleted). More practically, I find it super useful to fix issues when they arise in make check. But apparently fixing shutdown has fixed runtime on Windows (something to do with efreetd, ask vtorri). > > 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. > Yeah, it wasn't designed for it, that's pretty clear. I agree that in >99% of cases we don't care about clean shutdown, as long as tmp files are cleaned up, config is saved, etc... > > > > <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. > It'd be useful to tag these things properly so that we can get an idea of what could be part of a release and what could not :) > > > 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... > Yeah... :-/ Can't remember either... > > > 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 > > -- 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
