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. > > > > > > > > (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é ------------------------------------------------------------------------------ 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
