Note that the usage in efl_thread.c should and could be removed.
the problem with its usage is that when the ARGUMENTS event is fired,
noone ever had the chance to subscribe to the loop of the thread yet. So
all in all this is unneccessary, since noone could ever touch that.
Differential Revision: https://phab.enlightenment.org/D7517
Initial results of our static analysis showed a bunch of unused
imports or imports used only for documentation references. In the
first case, remove entirely, in the second case, change to 'parse'
in order to keep references working.
The static analysis is not perfect and yields false negatives for
certain cases, so there will be a second batch later.
this adds a simple indata and outdata void ptr to begin that you can
set on efl.thread objects (set the indata) and get the outdata too to
get results. then on the efl.appthread side the indata is set on the
efl.appthread before it runs and on quit the thresad can set the
outdata on the appthread, and this appears back on the efl.thread
object in the parent thread.
so you can basically share pointers to anything in and out this way on
start/exit in addition to string args etc.
the reason i made it an extra class (mixin actually) is for future
expansion. sharing more complex data - eina values maybe or objects as
long as they are shared objects, and perhaps acting as an interface
for calling a function at the other end like ecore_thread_async_call
etc.
so the MAIN loop is actually an efl.app object. which inherits from
efl.loop. the idea is that other loops in threads will not be efl.app
objects. thread on the creator side return an efl.thread object.
inside the thread, like the mainloop, there is now an efl.appthread
object that is for all non-main-loop threads.
every thread (main loop or child) when it spawns a thread is the
parent. there are i/o pipes from parnet to child and back. so parents
are generally expected to, if they want to talk to child thread, so
use the efl.io interfaces on efl.thread, and the main loop's elf.app
class allows you to talk to stdio back to the parent process like the
efl.appthread does the same using the efl.io interfaces to talk to its
parent app or appthread. it's symmetrical
no tests here - sure. i have been holding off on tests until things
settle. that's why i haven't done them yet. those will come back in a
subsequent commit
for really quick examples on using this see:
https://phab.enlightenment.org/F2983118https://phab.enlightenment.org/F2983142
they are just my test code for this.
Please see this design document:
https://phab.enlightenment.org/w/efl-loops-threads/
Marcel Hollerbach
WooHyun Jung
Daniel Kolesa
Carsten Haitzler