On Wed, 20 Dec 2017 11:19:30 +0900 Jean-Philippe André <j...@videolan.org> said:
> On Wed, Dec 20, 2017 at 11:10 AM, Carsten Haitzler <ras...@rasterman.com> > wrote: > > > On Tue, 19 Dec 2017 11:53:13 +0900 Jean-Philippe André <j...@videolan.org> > > said: > > > > > Hey raster, > > > > > > I'm confused by something, see ecore_test_ecore_main_loop_timer_inner, > > > and ecore_test_ecore_main_loop_event_recursive. > > > This test runs the main loop inside the main loop, which the > > documentation > > > says you shouldn't do. The test case passes because it's badly written > > > > indeed you shouldn't. we did at one point make the "ecore main loop > > iterate" > > func work... due to demand/requests for it... but it still is a bad idea > > to do > > this. it's quite possible my changes broke this... but the tests passed so > > i > > didn't look further. :) > > > > Well I disabled the tests. Your changes (or maybe another change prior to > that?) effectively prevent inner loops from existing. There's even a very > clear ERR message in that case :) hmm the tests didn't fail though... did they? > > > > > (marks the success variable before really running the test). It's not > > > testing that either of the inner timers even run. > > > > > > What's up with this? Did those inner loops use to work and then this > > became > > > forbidden? > > > > it was always forbidden... but due to requests by certain people who > > wanted to > > write recursive loops etc. we kind of made it work... but it's a pain to > > make > > this work and work right when someone could iterate or run a loop from any > > point in the call tree (inside a clicked callback/event from a button or > > the > > pixel get callback or glview paint callback etc. etc.)... imagine the hell > > that > > is trying to nest loops like this anywhere and everywhere? the advice > > stands: > > > > "don't do this". :) making it work universally is insanely hard without > > something failing somewhere. > > > > > > > On Mon, Dec 18, 2017 at 8:16 PM, Jean-Philippe André <j...@videolan.org> > > > wrote: > > > > > > > > > > > > > > > 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. > > > > 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 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. > > > > > > > > > > > > > > > > > > > >> > <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. > > > > > > > > > > > >> 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. > > > > > > > > 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. > > > > > > > > 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 :) > > > > > > > > > > > > > > > >> > > > >> > 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é > > > > > > > > > > > > > > > > -- > > > 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 ------------------------------------------------------------------------------ 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
