This changes a lot of things all across the EFL. Previously,
methods tagged @const had both their external prototype and
internal impl generated with const on object, while property
getters only had const on the external API. This is now changed
and it all has const everywhere.
Ref T6859.
For numeric types, eina_value_set() accepts values instead of references
on the value to be set. Hence, we were affecting as the exit code of the
loop a garbage value, yielding to invalid results.
so there is something broken in the complect efl promise/loop promise
that the clear of promises on loop destroy is clearing
promises/futures that have already triggered (loop timer ones). i've
spent enough time figuring out that it is happening.
_efl_loop_timeout_del() simple doenst ensure the future in
pending_futures for that promise is removed from the list. getting the
future from the promise handle is an exercise in pain... so i'm not
continuing with that path and will just ignore it.
but for now filling the promise data with null at least means if the
menory is re-used after free it wont see garbage freed ptrs and get
nulls so its easier to track.
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/
This reverts commit 135154303b.
Revert "efl: move signal events from efl.loop to efl.app"
This reverts commit 3dbca39f98.
Revert "efl: add test suite for efl_app"
This reverts commit 3e94be5d73.
Revert "efl: create Efl.App class, the parent of Efl.Loop"
This reverts commit 28fe00b94e.
Go back to before efl.app because I think this should be done with
superclassing here not a parent object. reasons?
1. multiple loops per single thread make no sense. so if multilpe loop
objects they wont be contained in a single app object and then deleted
like this.
2. the app object is not really sharable in this design so it cant be
accessed from other threads
3. it makes it harder to get the main loop or app object (well 2 func
calls one calling the other and more typing. it is longer to type and
more work where it is not necessary, and again it can't work from
other threads unless we go duplicating efl.app per thread and then
what is the point of splittyign out the signal events from efl.loop
then?)
etc.
this is astart of the work for having a common task class/interface
between loops, threads ane exe's so the i/o is all symmetric and works
the same way between all of them as well as similarly for launching
and knowing when the exit etc. etc.
this is not final and not perfect, but it's a start. comments of
course welcome
add efl_main_loop_steal() and efl_main_loop_release() for new efl
namespace versiosn of ecore_thread_main_loop_begin() and
ecore_thread_main_loop_end().
Gcc issues a warning here that 'main' is usually a function, so just
rename the variable to avoid the warning.
NB: No funtional changes
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This reverts commit f910ba248e.
The scheduler is meant to be used only in C, not by bindings so there isn't really
a use for it in the loop class. Now this patch was triggered due to complexity in
using future/promise, so will do a follow up patch to improve that.
also eina_procmis was not threadsafe so cannto use loops in different
threads at all until this was made safe. needed to disable the old
ecore_event using code in for ecore futures and create a new efl loop
message future and handler instead ... but now a quick experiment with
multiple loops in 10 threads plus mainloop have timers at least work.
i need to test more like fd handlers etc etc. but it's a step.
efl.loop was still using legacy ecore_timer_* calls inside. of course
this is a big no-no if we are to allow multiple loops, so clean this
up and convert them to efl.loop.timers.
There is no good reason to not shutdown a library properly. The loop
object can easily be deleted safely, if it is properly initialized. The
del event happens before destruction so it is too early to set the
singleton variable to NULL. Do that as late as possible and all calls to
efl_loop_main_get() will work as expected.
The issue with fd's was simply that they were not initialized to -1
(timer_fd), as some #ifdef statements have disappeared.
we really should have data inside the loop object, so begin moving it
one small thing at a time. this is the basics that will allow multiple
efl loops. make an eo efl object and class for fd handlers that is efl loop
bound make fd handlers really bound to their parent loop and not global as
well as have a nice class/obj. create an message queue per loop and
put legacy ecore events on top of it... and a lot more.
this is not 100% done, but it's a lot of the core and groundwork.
various ecore_timer_add(), ecore_diler_add() etc. need changes.
The following still need doing:
ecore_timer (internal usage for sure)
ecore_idler (internal usage for sure)
ecore_idle_enterer
ecore_idle_exiter
ecore_pollers? (is the new efl loop stuff ok?)
ecore_exe (fork/spawn from any thread and track exe from that thread?)
ecore_signal code
ecore_throttle (should we have a single global too? we have per loop)
ecore_app ? (should every loop be given its own argv/argc?)
Lots of internal ecore code uses/calls these legacy calls and we
should have efl loop replacements and/or use the ones we have
The following will bedifferently designed for loop to loop
control/messaging/ipc:
ecore_thread
ecore_pipe
Daniel Kolesa
Carsten Haitzler
Jean Guyomarc'h
Mike Blumenkrantz
Cedric BAIL
Chris Michael
Andy Williams
Jean-Philippe Andre