for some reason, the fallback thread would exit -> create timer ->
create idler -> create thread; the existence of the idler makes little
sense and introduces variability in the timer interval
@fix
Differential Revision: https://phab.enlightenment.org/D6441
threads should not be waited on here during shutdown since these same
threads may be waiting on the main loop anyway
instead, perform as much deallocation as possible,
mark the monitor as deleted, and then set the thread to canceled and
allow the thread to clean itself up during its cancel/end callback
@fix
Differential Revision: https://phab.enlightenment.org/D6440
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:
a common use case for mempools is that they get created by a thread but then
exist for the duration of the app's lifetime until shutdown() occurs in the
main thread. there is no reason to have an assert here which blocks that
use case
Depends on D6434
Reviewers: ManMower, bu5hm4n, devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6435
Summary:
ibus module will refuse to load if DISPLAY is not set, so avoid failing
for no reason in this case
Depends on D6433
Reviewers: ManMower, bu5hm4n, devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6434
Summary:
these tests explicitly call ecore_imf_init, so they must call ecore_imf_shutdown
even on failure cases to avoid propagating their failure to subsequent tests
ref T7085
Reviewers: ManMower, bu5hm4n, devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #committers
Tags: #efl
Maniphest Tasks: T7085
Differential Revision: https://phab.enlightenment.org/D6433
Summary:
drawing a non-override window before receiving a configure event results
in an unsized window, breaking spec. it also prevents ecore-evas resize
callbacks from triggering, yielding undefined returns from functions which
attempt to get the geometry of the ecore-evas
this patch improves upon the previous version by handling the case of windows
which are created with the correct initial size, bypassing an initial configure
event
there is still a lot of work to be done in this engine to improve/consolidate
resize-related code and ensure protocol correctness
ref T7008
fix T6907
Reviewers: devilhorns, ManMower
Subscribers: cedric, #committers
Tags: #efl
Maniphest Tasks: T7008, T6907
Differential Revision: https://phab.enlightenment.org/D6275
Summary:
When we add a plane we need to add it to the list before doing the atomic
test to ensure we're testing new state that includes the plane, and to
ensure the next screen update includes the plane we just added.
Fix T7066
Reviewers: devilhorns
Subscribers: cedric, #committers, zmike
Tags: #efl
Maniphest Tasks: T7066
Differential Revision: https://phab.enlightenment.org/D6432
Summary:
This reverts commit e0f8e65d20 which changed the
behavior of eina_stringshare_nprintf() and was not really needed to fix T6903.
Reviewers: zmike, Jaehyun_Cho, devilhorns
Reviewed By: zmike
Subscribers: cedric, #committers
Tags: #efl
Maniphest Tasks: T6903
Differential Revision: https://phab.enlightenment.org/D6431
Summary:
What happened before is that we registered efl_ui_leyout_legacy for
"elm_layout", which is not that good, since checking a (lets say) elm_button, for the type "elm_layout" would result in false. The same is with elm_button.
fixes T7081
Reviewers: devilhorns, zmike
Reviewed By: zmike
Subscribers: cedric, #committers, zmike
Tags: #efl
Maniphest Tasks: T7081
Differential Revision: https://phab.enlightenment.org/D6430
Summary:
I typod this in 14ae3e3dec and when using
mempools other than chained, this probably caused all apps to crash on
shutdown
Reviewers: ManMower, devilhorns
Reviewed By: ManMower
Subscribers: cedric, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6428
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
Summary:
each failure case should always be separate in order to provide the highest
degree of detail available if a test fails
Reviewers: devilhorns, ManMower
Reviewed By: ManMower
Subscribers: ManMower, cedric, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6373
Summary:
somehow backtrace() is able to generate EINVAL in certain cases even though
this is not documented anywhere. these irrelevant errors should not be noticed
by users of the api during debugging, as this can cause some tests/apps to
randomly fail without explanation
@fix
Reviewers: ManMower, devilhorns
Reviewed By: ManMower
Subscribers: cedric, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6377
Summary:
in the case where the first render took far longer then the specified
shot interval, this would end up recording garbage since there was nothing
drawn yet
@fix
fix T6929
Reviewers: bu5hm4n, JackDanielZ, devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #committers
Tags: #efl
Maniphest Tasks: T6929
Differential Revision: https://phab.enlightenment.org/D6426
Summary:
based on the codepaths taken when setting text to a part, a recalc should
only be necessary when returning markup from a textblock, and this is only
the case because the function returns a non-allocated string
in the case where the object is textblock and (legacy || not fetching markup),
the current text is guaranteed to be set on this pointer. the reason a
recalc is necessary for the markup case is because edje TEXTBLOCK parts only
set text to the internal textblock during a recalc, meaning that attempting
to fetch text on a just-set part will fail; this does not mean that the internal
textblock object doesn't exist, only that the text has not yet been set to it
Depends on D6422
Reviewers: herdsman, devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6423
Summary:
this adds perf overhead in order to work around a bug in text_get
all part objects are instantiated during edje_object_file_set, and forcing
a recalc here does nothing more than perform unnecessary operations
ref 8f95b17f39
ref D6365
Reviewers: herdsman, devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6422
Summary:
this changes the explicit pthread usage (and reimplementation of eina_thread_create)
to just use eina function calls. it also causes the thread to start and stop when
profiling is enabled and resolves some possible errors which could occur after
a fork or when trying to compile under windows
pthread usage: this code appears to have been 100% copied from eina_thread.c, and it
isn't clear to me why existing eina_thread api was not used. this has no functional
benefit, but it makes the code more readable
thread lifetime: there is no need to have a thread running at all times for a feature
which will be rarely used and which must be explicitly enabled by the user
windows: this file previously generated a lot of compiler warnings from unused functions
and variables since nothing here is available under windows. the entire file is now
a giant #ifndef _WIN32 to avoid any compile warnings or unexpected runtime behavior
fix T7055
Depends on D6371
Reviewers: ManMower, vtorri, devilhorns
Reviewed By: ManMower
Subscribers: cedric, #committers
Tags: #efl
Maniphest Tasks: T7055
Differential Revision: https://phab.enlightenment.org/D6372
this resolves some invalid read/write operations between threads without locking
and also attempts to improve thread-related behavior after fork() calls
ref T7027
Differential Revision: https://phab.enlightenment.org/D6370
Summary:
previously this used to mean 'the number of ms that a lock can wait for
until abort() is called once the lock is acquired' and it was useful
when trying to find contention issues with locks
unfortunately this required a bit of reading into the code to determine,
and it made the common case of setting values to 1 fail in some cases,
as this is a very short amount of time. also the documentation explicitly
gives '1' as an example setting for this variable, which will cause immediate
abort() in most cases when debugging was enabled since things are much slower
this variable now is the number of usec that a lock can wait for before abort()
is called, and the lowest value that will be checked for abort()ing is 100, meaning
that '1' is valid again
Depends on D6375
Reviewers: ManMower, devilhorns
Reviewed By: ManMower
Subscribers: cedric, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6376
Summary:
when debugging thread issues, it's not actually helpful to immediately
deadlock--this defeats any attempt at debugging. instead, call trylock first
in order to detect a possible deadlock and then throw an error which can be
caught by the user
Depends on D6374
Reviewers: ManMower, devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6375
Summary:
After a44697c37a, we can register same ecore_evas
to ecore_evases using ecore_evas_input_event_register.
(ecore_evas_input_event_register -> ecore_evas_done -> _ecore_evas_register)
This can make infinite loop in EINA_INLIST_FOREACH(ecore_evases, ee) because
next inlist of ecore_evases is ecore_evases after double call of
_ecore_evas_register.
This patch prevent it.
Test Plan:
Ecore_Evas *ee = ecore_evas_new(NULL, 0, 0, 800, 600, NULL);
ecore_evas_input_event_register(ee);
(part of document of ecore_fb_input_device_window_set)
Check that there is no infinite loop
Reviewers: zmike, devilhorns
Reviewed By: zmike
Subscribers: cedric, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6390
Summary:
if the user or system attempts to cancel this thread then it should
stop blocking and exit in order to avoid potentially exiting after
efl has expected ecore-con to stop being active
@fix
fix T7041
Depends on D6354
Reviewers: ManMower, devilhorns
Reviewed By: ManMower
Subscribers: cedric, #committers
Tags: #efl
Maniphest Tasks: T7041
Differential Revision: https://phab.enlightenment.org/D6355
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
there's no need to reimplement mempools here when we already have a great
mempool api
this makes the code slightly more readable
Differential Revision: https://phab.enlightenment.org/D6353
Mike Blumenkrantz
Hosang Kim
Carsten Haitzler
Mike Blumenkrantz
Derek Foreman
Xavi Artigas
Marcel Hollerbach
YeongJong Lee
Chris Michael