You've certainly raised some valid points which bear further looking into, thanks!
At a minimum, this patch was intended to introduce a base implementation of a singleton "app" object which could (and should) have tests written for it as it's improved upon. If you or others want to do that work feel free, I've moved on to other items for the near future. On Tue, Feb 27, 2018 at 12:07 AM Carsten Haitzler <[email protected]> wrote: > On Mon, 26 Feb 2018 11:03:03 -0800 Mike Blumenkrantz > <[email protected]> said: > > this change has a fair few problems to it... i don't think this is the > right > way to go. > > this change from efl_main_loop_get() doesn't make sense > > - job = efl_add(EFL_IO_MANAGER_CLASS, efl_main_loop_get()); > + job = efl_add(EFL_IO_MANAGER_CLASS, > efl_app_main_loop_get(efl_app_get())); > > you can't access the app object from anywhere other than the main loop > thread because it's a thread local object (the default)... so all this > does it > make this longer for no benefit. if can't be a shared object either > because you > also do things like: > > + EINA_LIST_FOREACH_SAFE(pd->loops, l, ll, loop) > + efl_del(loop); > > you want to have multiple loops in a single thread-local shared object? you > can't mix shared and non-share objects. this wouldn't even be able to > delete > the other loops belong to threads, and multiple loops in a single thread > just make zero sense. > > loops are intended to run a thread, not be multiple of them within a > thread. i > thought this had been discussed? the idea of 1 loop per thread. many > times. if > there is this, then the above will just never work because you can't delete > loops that belong to other threads (thread local objects) from the main > thread/loop. this will be full of invalid eoid's trying to be deleted. > > i think this design is wrong to have a separate app object that then > contains > loop objects etc. > > here is what i have been mulling and i think might be right: > > an efl.app or efl.mainloop class that INHERITS from efl.loop. i.e.: > > class Efl.App (Efl.Loop) > { > ... > } > > so the main loop will be of this efl.app or efl.mainloop class and then > other > loops in threads will be of the regular efl.loop class, not the efl.app > class. > no parent + child containing all the loops here and so no cross-thread > boundaries are crossed. then the efl.app or efl.mainloop class can have the > signal events move to it. the same main loop or app object we had before > stays, but it just gets a new class on top. > > it's simpler and won't have the above issues (and others i can begin to > see/imagining). you know if your loop is the main loop with efl_isa(loop, > EFL_APP_CLASS) on it. the efl_main_loop_get() can change to efl_app_get() > and > be shorter and sweeter, with perhaps later an efl_current_loop_get() that > gets > the loop for that thread from a TLS that works in threads and in main loop > too > once we have api to spawn threads and handle binding them together with > comms > pipes. > > it's simpler than your changes here and has fewer problems. i don't think > loops > will or should be children like you have above of an object. they have to > be > loosely coupled. they need to have just regular structs ptrs inside the > loop object to track child threads and how to communicate with them. to > delete > them you need to co-operatively request their delete e.g. via a pipe/fd > setup > to the other end, then the loop at the other end exits automatically when > it > gets this event/request on their end of the pipe and deletes itself. > > listen to the del event on the loop object to handle shutdown of anything > pending on that thread if you want to ensure you clean up anything you > created > on the thread end of things. actually any thread/loop probably has to wait > for > "child thread/loops" to exit before exiting itself (should join all the > thread's at a minimum). it can hold the exit request pending and keep the > loop > running until all children have reported back to have exited. this does > present > one possible exception - the main loop. should it wait too? that is a good > question, but definitely all other threads/loops should wait so we end up > with > a nice organized tree of threads/loops or ... tasks that have > "children" (thread/process thread/task children not object children) finish > before the parent does so you have a nice guaranteed cleanliness by > default at > least. > > i don't think you need to or have to do this... i can. it's been mulling > alongside the work i was doing for efl.exe etc. ... i wanted to flesh this > stuff out so i get a better picture of what goes where first and what it > will > look like. i was intending to make efl.thread object work first before > doing > the superclassing above. > > -- > ------------- 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
