Summary:
delete_cb is called at thread exit for each Eina_TLS keys used by the thread
Details:
posix:
pthread_key_create(key, delete_cb); does it
win32/wince:
eina_tls_free/new un/registers key&&cb into a static eina_list.
eina_tls_set add the key to an eina_list in Eina_Thread_Win3.
this list is cleared and callbacks are called in _eina_thread_join()
Test Plan: win32/wince has to be tested, I have no setup to do it.
Reviewers: cedric
CC: cedric
Differential Revision: https://phab.enlightenment.org/D489
It is sometime useful to start from a defined buffer, but to not touch it
until needed. This make life of caller more easier as they don't need to
duplicate the buffer themself as Eina will now take care of that.
We where inserting the pointer data instead of the pointer, leading to
unaligned access on Sparc (Thanks Lutin to report it and Debian tools/infra
to help us catch it) and also a memory leak.
this makes efl ignore certain env vars for thnigs and entirely removes
user modules (that no one ever used) etc. etc. to ensure that *IF* an
app is setuid, there isn't a priv escalation path that is easy.
vasprintf can return -1, in which case the buffer is corrupted.
So we better handle this ...
gcc told me of this thanks to -Wunused-result when building package,
thank you gcc for your incredible powers.
so firstly the module loading logic in emotion is pretty bad. it
forcible loads into memory (dlopen + run code from) EVERY emotion
module whenever you use emotion anywhere. this is a fat memory cost and
startup cost. it should not ever have done this. so remove that code
and make it explicitly load only the backend requested and fall back
to using what is compiled in (generic by default) and otherwise
generic as a module, then xine, then gstreamer then gstreamer1.
gstreamer1 seems broke - all i see is a black box (no video).
this also fixes a deadlock problem. if you have BOTH gstreamer AND
gstreamer1 modules loaded i get a deadlock inside glib. this seemingly
fixes it as it'll only load the first one it finds, not both (unless
explicitly requested).
Being annoyed by different types of eina critical macros - CRI, CRIT,
CRITICAL -, I concluded to unify them to one. Discussed on IRC and
finally, CRI was chosen to meet the consistency with other macros -
ERR, WRN, INF, DBG - in terms of the number of characters.
If there is any missing bits, please let me know.
it might have been free'd by the user, so set it to NULL before next
iteration. This is an attempt to fix CID 1039913 and 1039914.
We don't use the pointer value, only the pointer, so the error is wrong.
Could flag the error in coverity, but if this fixes it, we wont see the
error in other situations.
This is the correct implementation of the idea developped in Lucas De Marchi's blog :
http://www.politreco.com/2013/09/optimizing-hash-table-with-kmod-as-testbed/
This give an interesting +15% for all Eina_Hash user whatever hash function they use. The inlined
djb2 is still the fastest one and all other give very close result. It does increase memory foot
print, but as much as the previous way of doing it.
This is not perfect, it will just limit the propagation of the problem
for some time. Yes, it does hide it under the carpet, but that's better
than having a crash. Problem seems to be in Eina_Hash, but is really
difficult to reproduce and fix for the moment.
I have no idea how the previous formula was supposed to work at all, but
this one is the same as our alignof code to make sure we do allocate to
the really nearest size and don't do over allocation. Additionnaly it works.
eina_array_remove() didnt ever realloc down unless we went to 0
members. this wasn't very good as you'd expect the array to be reduced
in size if enough items were removed. not only that the old code was
stupid and ALWAYS malloc()ed a new array of the exact same size and
copied items over in the most complex way possible, then freed the old
one. this would have added overhead wherever used (evas_render) that
should not have been there.
this is based on the idea in a patch from
Viacheslav Lvov <v.lvov@samsung.com>, but this is a re-do of it
entirely, reducing the codebase massively even compared to the patch
and making it much simpler to read, maintain, actually reduce memory
and cut overhead.
Before this patch, we were unconditionnaly destroying the Eina_File if that one
did change on disk. We also make sure that we remove the right entry from the cache
if the file did change there.
The lock on the main hash was taken to late (after we took the decision
to remove the targeted Eina_File from the cache), this means it was possible
to get an Eina_File from the cache that was going to be removed. This patch
attempt to fix that potential race condition.
Hopefully should fix T461.
NOTE: EINA_VALUE_TYPE_DISPATCH_RETURN macro is a bit weird, it does
use external variable not passed to the macro and half of the parameter
given to it are just ignored...
Jérémy Zurcher
Carsten Haitzler
Cedric BAIL
Cedric Bail
Jihoon Kim
Guillaume Friloux
Dennis Schridde
Daniel Juyung Seo
Iván Briano
Sebastian Dransfeld
Boris Faure
Cedric BAIL