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
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
stealing the message data here prevents events which aren't being flushed from
ever being usable again and is unnecessary since the free callback will be
automatically called during the destructor
ref 5dd52fd09b
Summary:
This patch fixes a break of consistency of return data from ecore_event_del.
Before EFL 1.20, when calling ecore_event_add(ECORE_EVENT_SIGNAL_USER, event_data, NULL, &data);
The user data(data) is saved at event->data. and when user calls ecore_event_del(event_handler),
ecore_event_del returns event->data. However, current ecore_event_del returns pd->ev.
I think it is ABI break.
Test Plan: Execute test suite
Reviewers: cedric, raster, stefan_schmidt, Jaehyun_Cho
Reviewed By: Jaehyun_Cho
Differential Revision: https://phab.enlightenment.org/D5786
Summary:
This patch checks for the valid types.
As mentioned API reference documentation, user must know its type before hand.
The type should be chedked like previous efl version and ecore_event_type_flush_internal()
Test Plan: Execute a ecore test suite.
Reviewers: cedric, raster, jpeg, stefan_schmidt, Jaehyun_Cho
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D5776
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 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 :)
Xavi Artigas
Carsten Haitzler
Daniel Zaoui
Hermet Park
Daniel Kolesa
Mike Blumenkrantz
Cedric Bail
Shinwoo Kim
Jean Guyomarc'h
Marcel Hollerbach
Myoungwoon Roy, Kim
Hosang Kim
Vincent Torri
Andy Williams
Chris Michael