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.
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.
Summary:
it turns out that 0.01s is actually a lot, accounting for something like
20s across a run of 'make check' while providing no additional value
ref e0c8ab4c79
ref T6825
ref T6864
Reviewers: cedric
Maniphest Tasks: T6864, T6825
Differential Revision: https://phab.enlightenment.org/D5941
Reviewed-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
this is only meant to listen to data which is currently available,
not wait for new data
@fix
Depends on D5866
Reviewers: cedric
Reviewed By: cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D5867
Reviewed-by: Cedric Bail <cedric@osg.samsung.com>
Summary:
this resolves a race condition when a thread join was pending during
shutdown but a pipe write was needed in order for the join to be
successfully executed before shutdown had occurred
@fix
Reviewers: cedric
Reviewed By: cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D5866
Reviewed-by: Cedric Bail <cedric@osg.samsung.com>
[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.
well call sync returns a void * too.... instead of just void return
(nothing) but this makes it easier to write and maintain code due to
consistency of function callback signatures.
leave the exact numbers less defined because core count can change on
the fly and could be virtually limited by policy in future etc. so
keep things less exactly defined so people dont go depending on exact
results which was never really intended.
127 is the "command not found" shell exeit code, 126 is "the command
file is found but is not executable" which i think i'd interpret not
just for execute permissions but that something is preventing it from
executing in general.
both exe and thread objects must (currently) stay around until the
child thread or exe (task) is done. if you don't do this "bad things
can happen". so produce an error to let the programmer know.
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 this is then inconsistent with efl.exe and efl.thread, so go back
to being normal with 0'th arg being the binary itself jsut to make
sure we have conistent usage.
this adds a simple indata and outdata void ptr to begin that you can
set on efl.thread objects (set the indata) and get the outdata too to
get results. then on the efl.appthread side the indata is set on the
efl.appthread before it runs and on quit the thresad can set the
outdata on the appthread, and this appears back on the efl.thread
object in the parent thread.
so you can basically share pointers to anything in and out this way on
start/exit in addition to string args etc.
the reason i made it an extra class (mixin actually) is for future
expansion. sharing more complex data - eina values maybe or objects as
long as they are shared objects, and perhaps acting as an interface
for calling a function at the other end like ecore_thread_async_call
etc.
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.
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.
Some glibc versions declare pipe(2) with a warn unused result attribute,
leading to compile-time warnings when pipe(2)'s return value is not
checked.
If pipe(2) fails, we now print an error and make the calling function
fail.
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.
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