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:
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
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.
Some glibc declare write(2) with the attribute warn unused result.
So we now ensure that the calls to write(2) are successful. Otherwise,
we print an error and update errno accordingly.
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
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.
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.
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
Turns out there is no PRI?SIGATOMIC in the C99 standard. Work around
that by deducing the effective integer type by comparing the
SIG_ATOMIC_MAX with integers *MAX.
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Mike Blumenkrantz
Xavi Artigas
Cedric BAIL
Carsten Haitzler
Mike Blumenkrantz
Jean Guyomarc'h
Benjamin Jacobs
Guillaume Friloux
Vincent Torri