On Wed, 20 Dec 2017 13:23:22 +0900 Jean-Philippe André <[email protected]> said:
> On Wed, Dec 20, 2017 at 12:36 PM, Carsten Haitzler <[email protected]> > wrote: > > > On Wed, 20 Dec 2017 11:19:30 +0900 Jean-Philippe André <[email protected]> > > said: > > > > > On Wed, Dec 20, 2017 at 11:10 AM, Carsten Haitzler <[email protected] > > > > > > wrote: > > > > > > > On Tue, 19 Dec 2017 11:53:13 +0900 Jean-Philippe André < > > [email protected]> > > > > 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? > > > > No because they were badly written :) > But you would see an ERR in the logs. got it. ok. so i'm not crazy. they were not "FAIL"ing as in the check test case fail. but yes. nested loops is a problem. > > > > > (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é < > > [email protected]> > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > 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 > > > > > >> > [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é > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > 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] > > > > > > > -- > 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
