On Wed, 20 Dec 2017 11:58:21 +0900 Jean-Philippe André <[email protected]> said:
> On Wed, Dec 20, 2017 at 11:01 AM, Carsten Haitzler <[email protected]> > wrote: > > > On Mon, 18 Dec 2017 20:16:49 +0900 Jean-Philippe André <[email protected]> > > said: > > > > > On Sat, Dec 16, 2017 at 12:20 PM, Carsten Haitzler <[email protected] > > > > > > wrote: > > > > > > > On Fri, 15 Dec 2017 14:29:22 -0500 Cedric Bail <[email protected]> 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: [email protected] > > > > > > To: e <[email protected]> > > > > > > > > > > <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? :) actually a lot of the glibc stuff inits "on first use". :) that i have seen (basically still allocated memory on shutdown coming from inside glibc). > 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). eh? how? > > > 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... correct. shutdown really want intended for just that - cleaning out-of-process resources like tmp files etc. the question is... should init, shutdown, init, shutdown actually work? i don't think it should... this leads to implications on how to implement a shutdown 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 :) well i'm right now working on trying to fix the chain of mess that #undef EAPI has created... :) so i kind of don't want to context switch.... :) > > > > 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... :( i hope somehow we remember... or i'm going to just make it a loop method and say "you must cast"... :) > > > > 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 > > > > > [email protected] > > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > > > > > > > > > -- > > > > ------------- Codito, ergo sum - "I code, therefore I am" > > -------------- > > > > Carsten Haitzler - [email protected] > > > > > > > > > > > > ------------------------------------------------------------ > > > > ------------------ > > > > 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 > > > > [email protected] > > > > 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 > > > [email protected] > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > Carsten Haitzler - [email protected] > > > > > > > -- > Jean-Philippe André -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - [email protected] ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
