On Wed, 20 Dec 2017 18:36:30 +0000 Andrew Williams <a...@andywilliams.me> said:
> Since this came in the core_loop example is no longer working correctly. > https://git.enlightenment.org/tools/examples.git/tree/reference/c/core/src/core_event.c > > There are a few ERR about timers being dead and objects having parents that > didn't happen before. > Additionally a EFL_LOOP child of mainloop is created and a timer attached. > The timer no longer gets the TIMER_EVENT_TICK callback. > > Any hints as to where I should start looking to see what is broken? woooo... creating a loop that is a child of another loop in the same thread... sounds totally wrong. 1 loop per thread. at least for the legacy ecore calls - they will try and work on the mainloop singleton not the extra created loop. you COULD do this as long as everything is either in one loop object or the other cleanly. right now the internals are that some legacy calls are used internally. i made a note of that in my commit. at this point do not trust there being more than 1 loop object that actually works due to the above. in fact before my changes it was worse. all loops are in fact the same global singleton loop anyway as all data is in globals. before i think it worked by luck as 2 loop objects (the ecore singleton one and the one you created) were actually the same thing inside as they shared all the globals internally, so when the mainloop iterated it happend to use data you put into your new added loop. but putting a loop as a child of a loop is going to be a nasty proposition as a lot of the logic wants to walk back to the root object to find the loop. if it finds another loop along the way... what do we do? i never really looked into that or tested it. and indeed some objects may have parents they didn't have before. this seems to be a bit of a pervasive issue at some lower levels and in corners of efl that need to be ironed out before we can call our api or design stable or even close. now reading that sample... the nested loop is never run. so i think it worked by luck as i described above. not by design. (luck that the internals were shared due to it all being globals and the mainloop iterating happended to also iterate the child loop poller) just reading the code there... the loop you add is never actually run, thus i don't see how the _poll_cb could ever be called on it, as it's never iterated. well not logically by api design and intent. it was just by pure accident. > Thanks, > Andy > > On Wed, 20 Dec 2017 at 04:28 Jean-Philippe André <j...@videolan.org> wrote: > > > On Wed, Dec 20, 2017 at 12:41 PM, Carsten Haitzler <ras...@rasterman.com> > > wrote: > > > > > On Wed, 20 Dec 2017 11:58:21 +0900 Jean-Philippe André < > > j...@videolan.org> > > > said: > > > > > > > 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? :) > > > > > > 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? > > > > > > > Maybe Vincent could enlighten us, but I think he doesn't know the details > > either: > > > > <vtorri__> edje hanged , displaying indefinitly eina error message with > > spinlocks and efreetd/efreet_desktop_cache was closing and launched again > > and again > > <vtorri__> i had to reboot my computer > > > > > > > > > > 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. > > > > > > > I believe we can agree on this: it's useful for testing but belongs to > > "undefined" behavior otherwise. I mean, it's not meant to work. > > > > But when we'll deal with multiple loops and all that, you will want a clean > > destruction of the loop object. > > > > > > > > > <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"... :) > > > > > > > All I can remember was that the event info in the callback had a type known > > at compile time, and that would be super useful for C++. > > > > > > > > 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é > > > > > > > > > -- > > > ------------- 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 > > > -- > http://andywilliams.me > http://ajwillia.ms -- ------------- 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
