Compiling using -Dglib=true and -Dg-mainloop=true causes glib errors every time when efreet_icon_cache_create is invoked (ex., run and stop elementary_config and observe the terminal output).
So, i added error message in place where ecore_glib_source may be undefined. The issue was with undefined ecore_glib_source variable in _ecore_main_loop_setup function. Here _ecore_main_fdh_poll_add was used before actual ecore_glib_source definition.
@fixed
This reverts commit e2d6691d52.
This reverts commit c02b796fdb.
This reverts commit 6c969f6b7d.
This reverts commit 74204bccd7.
This reverts commit 1304d95717.
This reverts commit 7c85be9674.
revert the EAPI changes that break cxx bindings build. sorry :( more
fixes needed than i thought
Summary:
= The Rationale =
EAPI was designed to be able to pass
`__attribute__ ((visibility ("default")))` for symbols with
GCC, which would mean that even if -fvisibility=hidden was used
when compiling the library, the needed symbols would get exported.
MSVC __almost__ works like GCC (or mingw) in which you can
declare everything as export and it will just work (slower, but
it will work). But there's a caveat: global variables will not
work the same way for MSVC, but works for mingw and GCC.
For global variables (as opposed to functions), MSVC requires
correct DSO visibility for MSVC: instead of declaring a symbol as
export for everything, you need to declare it as import when
importing from another DSO and export when defining it locally.
With current EAPI definitions, we get the following example
working in mingw and MSVC (observe it doesn't define any global
variables as exported symbols).
Example 1:
dll1:
```
EAPI void foo(void);
EAPI void bar()
{
foo();
}
```
dll2:
```
EAPI void foo()
{
printf ("foo\n");
}
```
This works fine with API defined as __declspec(dllexport) in both
cases and for gcc defining as
`__atttribute__((visibility("default")))`.
However, the following:
Example 2:
dll1:
```
EAPI extern int foo;
EAPI void foobar(void);
EAPI void bar()
{
foo = 5;
foobar();
}
```
dll2:
```
EAPI int foo = 0;
EAPI void foobar()
{
printf ("foo %d\n", foo);
}
```
This will work on mingw but will not work for MSVC. And that's why
EAPI is the only solution that worked for MSVC.
Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com>
Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev>
Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
Reviewers: vtorri, raster
Reviewed By: raster
Subscribers: raster, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12271
so i've moved all systemd and elogind support to be runtime only with
dlopen (eina_module) of libsystemd.so.0 (or libelogind.so.0 for elput)
and finding of symbols manually at runtime (if the right code paths or
env vars are set), thus remvoing the need to decide at compile time if
efl needs systemd support or not as it no longer needs systemd
headers/libs at compile time and just at runtime. this simplifies
building a bit and makes efl more adaptive to the final target system
at runtime.
Summary:
it's possible that _ecore_get_epoll_fd() can return -1, so ensure that we
correctly handle this
CID 1383850
Reviewers: devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10394
Summary:
it seems like this was intended to be handled already, but somehow it wasn't...
ref T8321
Depends on D10358
Reviewers: cedric
Reviewed By: cedric
Subscribers: bu5hm4n, cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T8321
Differential Revision: https://phab.enlightenment.org/D10359
this is a performance optimization. it brings in a "stat generation".
for now it's disabled by default so we retain previous behavior. this
stops eina file from opening and stating a file every time you open
... it only does it if stat generation is off, or, if the generation
changed since the last time it opened that file. this makes cache hits
not have a 3 syscall cost (open+fstat+close). this optimizes that
lower end of things path. but .. it comes at a cost. if the file
changes before generation ticks over (which this forces to tick over
every time the loop exits idle by default).
now here is something to ask.
1. should we have this on by default and accept the "inexactness"
since you can eina_file_statgen_next() before any call that would do
i/o to force it to look at the real file stat info...
2. should we tick over every idle enter OR every N idle enters or
every frame we render instead? ... i want to avoid getting a timestamp
or having a timer interrupt often... so what should we do?
at least this introduces the idea, some api's and an env var to turn
this on. it definitely cuts down syscalls during things like creation
of widdgets or objects in large batches etc.
in the case where ecore_main_loop_quit() was called before ecore_main_loop_begin(),
the latter call would exit immediately without ever iterating the main loop
@fix
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9360
This allows an fd handler to be called after select exits unconditionally.
Our wayland client code needs this to be thread safe, as it needs to
call prepare_read before entering select, and then either read or
cancel_read after select.
Signed-off-by: Derek Foreman <derek.foreman.samsung@gmail.com>
Reviewed-by: Chris Michael <cp.michael@samsung.com>
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D7914
Summary:
This allows an fd handler to be called after select exits unconditionally.
Our wayland client code needs this to be thread safe, as it needs to
call prepare_read before entering select, and then either read or
cancel_read after select.
Reviewers: cedric
Reviewed By: cedric
Subscribers: zmike, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7914
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:
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
The value must be given to eina_value_set and not a pointer to a
Eina_Value.
This bug results in always getting wrong exit code when the application
terminates.
[Dereference after null check]
(1) src/lib/ecore/ecore_main.c
- _efl_loop_handler_efl_object_finalize checks if pd->loop_data is NULL.
After that, _handler_reset > _handler_clear > _ecore_main_fd_handler_del >
_ecore_main_fdh_pool_del is directly dereferencing pd->pool_data.
- _efl_loop_handler_efl_object_parent_set checks if pd->loop_data as well.
Then it calls _handler_reset as well.
(2) src/lib/ecore_wayland/ecore_wl_dnd.c
- ecore_wl_dnd_selection_set checks if t - result of wl_array_add - is NULL.
And it is dereferecing t directly for wl_data_source_offer.
(3) src/lib/elementary/efl_ui_dnd.c
- Third parameter const char *data could be NULL.
In this case strlen dereferences NULL. The data should be non NULL value.
I have checked this with Mr. Thiep Ha.
(4) src/lib/evas/canvas/evas_object_inform.c
- _efl_canvas_object_efl_gfx_stack_stack_below checks if obj->layer is NULL.
So it could call evas_object_inform_call_call_restack which is dereferencing
obj->layer directly.
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.
if its a non-legacy loop handler that also binds an fd handler
internally (the 2 things are linked as a pair) then on loop del, dont
del the objet as the obj del should handle things elsehwere.
odd - i found ecore fd handlers basically ignored hangups from the
other end so we never knew if the other end went or not... crazy. now
we at least have all the read/write/error flags on and the next read
should fail indicating the broken pipe etc. ...
@fix
Summary:
This patch checks for the valid Ecore_Fd_Handler_Flags.
The flags should be checked like previous verion because
There are no default handlings in case of out of Ecore_Fd_Handler enum values in other funcs.
Test Plan: Execute a test case
Reviewers: cedric, raster, jpeg, stefan, Jaehyun_Cho
Differential Revision: https://phab.enlightenment.org/D5775
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
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
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
Dmitri Chudinov
Carsten Haitzler
Felipe Magno de Almeida
Mike Blumenkrantz
Vincent Torri
Derek Foreman
Christopher Michael
Taehyub Kim
Alastair Poole
Thierry HUCHARD
Cedric BAIL
Daniel Zaoui
Shinwoo Kim
Mike Blumenkrantz
Myoungwoon Roy, Kim
Jean-Philippe Andre