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 :) > > > (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é ------------------------------------------------------------------------------ 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
