Summary: I had fixed some typos and some wrong expressions in API reference doc
Test Plan: N/A
Reviewers: raster, zmike, Hermet, segfaultxavi
Reviewed By: Hermet
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6943
Summary:
it is not correct to throw an error when methods are called during
construction
Reviewers: Hermet
Reviewed By: Hermet
Subscribers: Hermet, cedric, #reviewers, #committers
Tags: #efl_main_loop
Differential Revision: https://phab.enlightenment.org/D6787
Summary:
Ecore internally uses 10 events, from ECORE_EVENT_SIGNAL_USER=1 to
ECORE_EVENT_SYSTEM_TIMEDATE_CHANGED=10. The Ecore.Event.Message_Handler
singleton that holds the counter of events is initialized with -1.
This is followed in _ecore_event_init() by ten calls to
ecore_event_message_handler_type_new(), which increase the counter of
event by one each.
This results in an event counter to be 9 (-1 + 10) at the end of the
initialization of ecore_events. This means that the next event to be
created will have a value of 10, which will overlap with
ECORE_EVENT_SYSTEM_TIMEDATE_CHANGED. As such, these two distinct events
will be aliased and their associated handlers will be called at
unexpected times, with unexpected data.
By changing the constructor value from -1 to 0, we prevent this event
aliasing.
Fixes T6605
Reviewers: zmike, Hermet
Reviewed By: Hermet
Subscribers: cedric, #reviewers, #committers, zmike
Tags: #efl
Maniphest Tasks: T6605
Differential Revision: https://phab.enlightenment.org/D6894
Summary:
This reverts commit 4917910b49.
4917910b break backward compatibility.
Reproduction:
void pipe_handler(...);
pipe = ecore_pipe_add(pipe_handler, NULL);
ecore_pipe_write(pipe, NULL, 0);
Because of the null check condition, pipe_handler isn't called after 4917910b.
Some apps behavior which is written to expected to call pipe_handler was broken.
also, this patch fixed segfault during build on Windows
Test Plan: make on Windows
Reviewers: raster, zmike, vtorri
Reviewed By: zmike, vtorri
Subscribers: woohyun, cedric, #reviewers, #committers, zmike, vtorri
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6824
Summary:
in the case where the user has called loop_time_set with a value in the future,
avoid setting the loop time to something that would potentially cause a callback
to occur with a loop_time value before a previous occurrence of that callback
@fix
Reviewers: ManMower
Reviewed By: ManMower
Subscribers: ManMower, #reviewers, cedric, #committers
Tags: #efl_main_loop
Differential Revision: https://phab.enlightenment.org/D6764
Summary:
Timers are not called in the order they were registered.
Because when current timer is deleted, getting next timer is called twice.
Test Plan:
<error>
Timer1 expired after 0.001 seconds.
Timer3 expired after 0.001 seconds.
Timer5 expired after 0.001 seconds.
Timer7 expired after 0.001 seconds.
Timer2 expired after 0.001 seconds.
Timer6 expired after 0.001 seconds.
Timer4 expired after 0.001 seconds.
Timer8 expired after 0.001 seconds.
<correct>
Timer1 expired after 0.001 seconds.
Timer2 expired after 0.001 seconds.
Timer3 expired after 0.001 seconds.
Timer4 expired after 0.001 seconds.
Timer5 expired after 0.001 seconds.
Timer6 expired after 0.001 seconds.
Timer7 expired after 0.001 seconds.
Timer8 expired after 0.001 seconds.|
{F3268233}
Reviewers: Hermet, Jaehyun_Cho, zmike, SanghyeonLee
Reviewed By: zmike
Subscribers: cedric, #committers, zmike
Tags: #efl_tests
Differential Revision: https://phab.enlightenment.org/D6700
Summary:
attempt to prevent any access of the signal pipe once signal handlers are
removed in order to avoid triggering a SIGPIPE which would kill the app
Depends on D6670
Reviewers: ManMower
Reviewed By: ManMower
Subscribers: cedric, #committers
Tags: #efl_main_loop
Differential Revision: https://phab.enlightenment.org/D6672
Summary:
if a signal is already in the signal pipe when close() is called,
this will trigger a SIGPIPE. if the signal handler exists, this will
cause the signal handler to infinitely recurse when trying to print
the error messages from write()ing the signal data to the close()d
pipe
fix T7158
Reviewers: ManMower
Reviewed By: ManMower
Subscribers: cedric, #committers
Tags: #efl_main_loop
Maniphest Tasks: T7158
Differential Revision: https://phab.enlightenment.org/D6670
Summary:
windows does not include ecore_signal.c, so this is not a defined symbol
lib/ecore/.libs/lib_ecore_libecore_la-ecore_anim.o: In function `timer_tick_notify':D:\Documents\MSYS2\home\vtorri\gitroot\efl3\src/lib/ecore/ecore_anim.c:372: undefined reference to `exit_signal_received'lib/ecore/.libs/lib_ecore_libecore_la-ecore_anim.o: In function `ecore_animator_custom_tick':D:\Documents\MSYS2\home\vtorri\gitroot\efl3\src/lib/
ecore/ecore_anim.c:940: undefined reference to `exit_signal_received'
ref 6405a5a68c
Reviewers: vtorri, devilhorns
Reviewed By: vtorri
Subscribers: cedric, #committers
Tags: #efl_build
Differential Revision: https://phab.enlightenment.org/D6648
Summary:
Silence compilation warning.
There is an ifdef'd block of code which accesses obj but
I don't think it's in use in production?
Test Plan: Build EFL and watch for warning.
Reviewers: #committers, zmike, Hermet
Reviewed By: #committers, Hermet
Subscribers: cedric
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6628
Summary:
when an exit (SIGINT, SIGQUIT, SIGTERM) signal is received, the ui should
immediately stop updating in order to present the user with an instant
response
this uses a simple volatile int to block any ticks which begin after the
signal is received; if a signal is received during a tick then it will complete
normally
fix T7000
Depends on D6589
Reviewers: ManMower
Reviewed By: ManMower
Subscribers: cedric, #committers
Tags: #efl_main_loop
Maniphest Tasks: T7000
Differential Revision: https://phab.enlightenment.org/D6590
Summary:
When closing the fd handler, it checks if the fd is already closed and prints
an annoying warning: "fd %d closed, can't remove from epoll - reinit!"
We need to close the handler first and then the actual fd.
I am not familiar with this part of the code, but this fix removes the warnings
and does not seems to have adverse effects.
Test Plan: It had warnings before and now it doesn't, haven't observed any other adverse effect.
Reviewers: raster, zmike, devilhorns
Reviewed By: zmike
Subscribers: cedric, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6561
Summary:
We should only ever have a pos of 1.0 once, the current terminal
condition gives the impression that it might be possible to have
more than one 1.0 firing.
This would break a lot of code.
No functional change intended.
Depends on D6464
Reviewers: devilhorns, zmike
Reviewed By: zmike
Subscribers: cedric, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6465
this avoids the case where the main loop is waiting on a thread
and that same thread is waiting on the main loop
@fix
Differential Revision: https://phab.enlightenment.org/D6438
if a thread is actively waiting on the main loop in order to proceed
with its exit, a flush here avoids the case where the thread waits
until the main loop has exited
Differential Revision: https://phab.enlightenment.org/D6437
since this is now a smaller wait interval, looping more times helps
ensure success for threads which have longer blocking operations
between lifetime checks
Differential Revision: https://phab.enlightenment.org/D6436
Summary:
now that ecore accurately waits on all threads while exiting, this
loop needs to run much more frequently in order to avoid waiting for
an unreasonably long time when exiting
Reviewers: ManMower, devilhorns
Reviewed By: ManMower
Subscribers: cedric, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6427
these threads are still managed by the main loop, meaning they must be
accounted for so that they can be waited on if necessary during shutdown
this resolves some issues where ecore-con threads would persist after the
main thread had exited or called ecore_shutdown
@fix
fix T7041
this is the final version of the patch and not the mangled version which
was previously committed
Differential Revision: https://phab.enlightenment.org/D6354
these threads are still managed by the main loop, meaning they must be
accounted for so that they can be waited on if necessary during shutdown
this resolves some issues where ecore-con threads would persist after the
main thread had exited or called ecore_shutdown
@fix
fix T7041
Differential Revision: https://phab.enlightenment.org/D6354
these headers are not available on all platforms (e.g., windows) and so
the corresponding #ifdef checks must be used in order to correctly include
them
ref 1adb73cef8
ref T5725
fix T7063
Differential Revision: https://phab.enlightenment.org/D6369
Summary:
ensure that this occurs as expected when forks happen
note that this is already being actively tested in the elm unit tests
Depends on D6307
Reviewers: ManMower, devilhorns
Reviewed By: ManMower
Subscribers: cedric, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6308
Glib integration with using of select() syscall doesn't properly
propagates G_IO_ERR condition for network sockets. Problem relies in
_ecore_glib_context_poll_to() where rewriting filedescriptor events to
GPollFD structures reside.
This fixes T5725
@fix
Summary:
Animators shouldn't be used as a general purpose timer mechanism,
we could use a timer, but a poller seems to make more sense as
it limits the impact of the instrumentation on the code it's
instrumenting.
Reviewers: stephenmhouston, zmike
Reviewed By: stephenmhouston, zmike
Subscribers: stephenmhouston, cedric, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6251
Summary:
All events must have a type now, otherwise bindings don't know how to handle
the event_info field.
Most of the missing event types were actually "void" (no event_info present).
Some struct definitions had to be moved to eo instead of h files, so they
are available to bindings. Some have not, and are marked with FIXME.
Some namespaces have been fixed (like Efl_Event_Cb -> Efl.Event_Cb).
In general, there are hundreds of changed files, but mostly to add a type which
was not present before, so there's no harm done.
Also, A lot of FIXMEs have been added which should be, like, fixed.
For example, some events can send different types of event_info, which is
very inconvenient (and error prone).
Test Plan: make with c# bindings works, make check and make examples work too.
Reviewers: cedric, q66, lauromoura
Subscribers: zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6169
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.