Summary:
This patch checks whether the callback function is valid or not.
Callback function must be set up for the class.
Test Plan: Execute test suite
Reviewers: cedric, raster, stefan, Jaehyun_Cho
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D5762
Summary: This patch fixes a tentative crash owing to dereference of fd_handler.
Test Plan: Execute test suite
Reviewers: cedric, raster, stefan, Jaehyun_Cho
Reviewed By: Jaehyun_Cho
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D5754
Summary:
This patch fixes a tentative crash owing to null ptr dereference
ecore_animator_freeze() has a same patch already.
Test Plan: execute test suite
Reviewers: cedric, raster, jpeg, stefan, Jaehyun_Cho
Reviewed By: Jaehyun_Cho
Differential Revision: https://phab.enlightenment.org/D5752
remove thread code since osx is not happy with threads trapping
signals (or at least a thread setting up the handler and trapping
there with signal blocks...). this should now work universally.
we used to do signals on main loop. keep doing. the pipes should work
in cleanly serializing the signals irrespective of when/where they are
caught (because we do into kernel and back out again). hoping this
makes osx work again. can't test as i have no osx box or vm. works on
linux and freebsd though.
this willonly apply to the main loop, but to be able to see these
signals as callbacks, we have to expose them. term/quit/int are
already handled internally where the loop will terminate (efl will
enforce this) AND ... there is a terminate event already on the loop
to deal with this cleanup. other signals really arent applicable IMHO
except usr1/2 and hup.
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.
stop using the legacy ecore_loop_time_get() func when it should be
coming from the loop object's loop time. also ecore_time_get should
never fall back on ecore_loop_time_get for similar reasons.
part of making the ecore/efl loop a non-global instance (allow loops
in threads)
so loop object destruction was clearing out fd handlers but those may
be later deleted by destructors of child objects. so leave legacy
fdh's and just remove them from the list
This has been bugging me for some time but now we are triggering new errors internally
this is appearing to end users for problems they did not cause.
Additionally I was able to improve a couple of the errors by copying the
explanation from code comments into the error message.
Shorter error logs now too :)
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.
According to comments by @k-s & @raster.
See 784a5b56a3 this was intended to be a fallback, not the first
lookup indeed. Since this is an error case, let's print an ERR message
at least.
Not a fan of the solution, as I think some of the logic handling those
futures is a bit broken. I'm not 100% sure about this patch. But this
improves make check with CK_FORK=no in elm_suite.
If the object has no parent or anything else goes a bit wrong,
efl_loop_get() may fail to return the loop object. It's a bit ridiculous
when we're in the main loop as we know which loop object was requested.
This avoids returning NULL.
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.
Myoungwoon Roy, Kim
Mike Blumenkrantz
Vincent Torri
Carsten Haitzler
Cedric BAIL
Andy Williams
Chris Michael
Jean-Philippe Andre