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
