I knew Windows doesn't allow statically initialising pointers in the
global namespace, I had no idea it also applies to functions. That's
quite annoying.
Thanks to Cedric for reporting.
It has been discussed on the ML (thread: "[RFC] rename efl_self") and
IRC, and has been decided we should rename it to this in order to avoid
confusion with the already established meaning of self which is very
similar to what we were using it for, but didn't have complete overlap.
Kudos to Marcel Hollerbach for initiating the discussion and
fighting for it until he convinced a significant mass. :)
This commit breaks API, and depending on compiler potentially ABI.
@feature
As far as I remember, declaring structures and arrays in a cast is a GCC
extension. I'm not 100% sure I'm right, but I remember it was the case.
Regardless of whether it's an extension or not, this commit removes that
pattern and makes everything cleaner (and faster?).
This is another follow up to the investigations of T4227. As stated
there, in any PIE (a shared library is one), structures, even const ones
end up being written to because of dynamic relocation. This means that
using static const structures has actually lead to no savings, only
waste. Since we never really needed them, using them made things even
worse than just having a different API that doesn't save them.
Thus, this commit changes the way we set the functions. Instead of
passing a pre-populated struct, we now just have an initialiser function
where you set the functions. This on its own doesn't significantly reduce
the amount of dirty memory pages for a reason I have yet to uncover,
though I believe it's done as a misguided compiler optimisation.
However, this design is flexible enough so we can change to another one
that is quite ugly, but I have already tested and proven that does that.
This patch series doesn't include the better improvement (passing
everything on the stack as va_args) because the API was too ugly
for me to bear, and I would rather first make sure there is no way to
force the compiler to do the right thing here.
Unfortunately this commit gives up on useless stricter validation.
Before this commit we would make sure that we are only overriding
functions correctly defined in our hierarchy. With this one, we don't
anymore. This is not a big problem though because this is a check that
is also enforced by Eolian. So as long as you are using Eolian, you
should be fine.
Breaks API and ABI!
@feature
This improve speed of processing events in genlist scrolling benchmark by 30%
inside the efl_object_event_callback_call code. Not a really big deal as it
goes from 0.9% to 0.6% of the total time spend. Welcome to micro optimization.
This was never used and there is no plan to ever use it. I'm going to
soon add a different mechanism with which it will be possible to provide
them again to Eo if ever needed without breaking ABI. Though it's
unlikely it will ever be.
So it may be used outside EO (eina error is what I have in mind).
I believe it doesn't need to be redefined in all EFL libs, especially
since it's not used on Windows yet.
Clang raised the warning:
redefinition of typedef 'Efl_Object' is a
C11 feature [-Wtypedef-redefinition]
for every compiling unit including Eo.h, which
caused a huge console pollution during compilation.
ok. so here's the issue at least now. we have eo objects in the canvas
and they have a refcount of 2 user_refcount is 0. the calls stack does
NOT show we are calling callbacks at that time on these objects. they
are not in the backtrace (the canvas is, the objects themselves are
not).
SOMETHING is keeping 2 eo "internal" refs on these objects and i have
no idea what/how/who. it's a royal pain in the butt to find out as the
only way is lots and lots of logging and you get drowned in the
logging...
so what I have now done is a super ugly workaround that detects these
zombie objects that refuse to die and just FORCES them to die when the
evas canvas frees and clears out layers.
ac10a00acc doesn't really cause the
issue, it just brings it out in the open for all to see far more
easily. but something is deeply wrong SOMEWHERE with SOME objects and
our refcounts.
this fixes T4187
This is a (minor) API & ABI break in Eo.h!
I say minor as eo_override shouldn't be used yet (EO is unstable
and this patch includes all the use cases in EFL).
I'm not very happy about the new form of the macro, but it avoids
two things:
- passing in a struct (valid in C, but never used in EFL)
- using a GCC construct to create structs on the fly
It was inspired by the event array define, but I don't think
we need the runtime memcpy here.
See also:
https://gcc.gnu.org/onlinedocs/gcc/Compound-Literals.html
When using eo_add_ref, it was increasing the refcount before the user
context in the addition has fully ended. This means the object had its
reference increased while still not finalized, which means it was
sometimes passed with an increased refcount to unsuspecting class code.
The correct behaviour is to increase the reference count just before
returning the object to the user at the end of eo_add so the reference
count is only increased for whoever asked for it.
Breaks ABI!
@fix
Somehow, there was code in the tree that apparently isn't tested at all, even
once - if it was, the eo.c logic that performs inheritance checks would be
triggered. I don't know how this could have happened (actually I do, it's
Cedric's fault and he should be publicly shamed for it) but these checks
make sure this will never happen again. But since the code itself appears
to be untested, I don't know if there isn't any other brokenness in it.
But that's beyond the scope of this change, so for now, let's make sure
all our inheritance is at least formally correct.
Also, enable eo_interface.eo generated code in Eo itself so that Eo.Interface
can be used when inheriting.
@fix
This reverts commit 546ff7bbba.
It seems that eo_del() is useful and removing it was creating bugs.
The issue is that the way we defined parents in eo, both the parent and
the programmer share a reference to the object. When we eo_unref() that
reference as the programmer, eo has no way to know it's this specific
reference we are freeing, and not a general one, so in some
circumstances, for example:
eo_ref(child);
eo_unref(child); // trying to delete here
eo_unref(container); // container is deleted here
eo_unref(child); // child already has 0 refs before this point.
We would have an issue with references and objects being freed too soon
and in general, issue with the references.
Having eo_del() solves that, because this one explicitly unparents if
there is a parent, meaning the reference ownership is explicitly taken
by the programmer.
eo_del() is essentially a convenience function around "check if has
parent, and if so unparent, otherwise, unref". Which should be used when
you want to delete an object although it has a parent, and is equivalent
to eo_unref() when it doesn't have one.
so... i got this ... callback calls callback calls something calls
callback that deletes the original object at the top so when it comes
back ... things die as the object was destructed. in removing eo_do()
we removed the ref/unrefs that went with it. so this uses the
_EO_API_BEFORE_HOOK and _EO_API_AFTER_HOOK to call exposed "internal"
public functions _eo_real_ref() and _eo_real_unref().
this fixes a new segv i've noticed in several e dialogs where hitting
close does the above via callbacks and closes the window etc.
Apparently you can't cast when initializing static consts, even if
the cast is to the same type. This commit splits the macro used
so we have an additional one that casts and thus works with
eo_override().
This change lets you override the functions of objects so that those
functions will be called instead of the functions of the class. This
lets you change objects on the fly and makes using the delegate pattern
easier (no need to create a class every time anymore).
You can see the newly added tests (in this commit) for usage examples.
@feature
We used to have eo_del() as the mirrored action to eo_add(). No longer,
now you just always eo_unref() to delete an object. This change makes it
so the reference of the parent is shared with the reference the
programmer has. So eo_parent_set(obj, NULL) can free an object, and so
does eo_unref() (even if there is a parent).
This means Eo no longer complains if you have a parent during deletion.
In some build environment, anonymous char delcaration can be interpreted
as "unsigned char". Although lk_init can be only 0, 1 or 2 so there
won't be any unexpected result. This change is just to make static code
analyzer happy.
Because we were forcing EWAPI in this macro, one couldn't create a class
that is "static" or even just private or the module. The symbol was
always exposed.
Since in C the attributes of a function are set based on the first
declaration, we don't need to specify any attributes in this macro and
we can just rely on them being specified in the declaration. So for
example, for class "foo":
foo.h:
EWAPI const Eo_Class *foo_class_get(...);
foo.c:
const Eo_Class *foo_class_get(...);
Would give the desired results, a class would be EWAPI. This is already
done automatically for all of the classes using Eolian. Because of the
lack of specifiers, the default visibility will now be the default
visibility based on compiler flags and settings.
Thanks to JP for reporting this issue.
This can potentially (but very unlikely) break things.
This was done following a feature request by @raster. There was no real
reason for it not to be an eo function and this gives us more
flexibility.
The reason why this done was to provide a way for classes to do special
things when an object deletion was requested, for example in the case of
Evas, hide the object.
The idea is that when you are processing those events from within
they won't call twice any of the event until all of them are processed
at least once (Or one of them did return EINA_FALSE).
Modify the way hooks are defined and used by promise generation in
Eolian in the Eo API.
Instead of passing macro names as parameters to EO_FUNC_BODY macros,
just re-define the actual hooks when it is needed.
For windows, EAPI needs to be redefined as dllexport/dllimport.
Since we marked all EO APIs as weak, we had two different EAPI
macros: EAPI and EWAPI. Unfortunately, EWAPI was never redefined
(only declared inside Eo.h).
See also a1a506e13e.
See T3423. Thanks @vtorri for the report.
While eolian-gen was generating EWAPI (weak) class_get()
symbol declarations, they were implemented as EAPI (strong).
Not sure if this mismatch had any significant effect.
This patch tries to address T3423 (windows build).
The mismatch between EAPI and EWAPI might be the problem.
Add two parameters for macros that generate API functions in Eo so
that the generation can be customized with macros used by Eolian.
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
The function call resolve cache may be broken after an eo
shutdown + init cycle, leading to calls to invalid functions.
This adds an static uint for each and every single EO API
entry point, as well as an extra if() check.
Now I'm not sure if the previous commit 0862b9d083 is
still necessary.
This marks all EOAPI functions with GCC weak attribute.
This allows two things:
- replace functions
- link at runtime and check if functions exist
The purpose of this patch is to exploit these two features
of weak symbols. The first goal is to allow applications
to build binaries against later versions and run on earlier
versions of EFL without any run-time link error. Those errors
simply prevent applications to even start if they were using
any function that's not present in the old version of EFL.
Now all that needs to be done on the application side is to
do either of:
- if (efl_version > xx) { call_weak_symbol() }
- if (call_weak_symbol) { call_weak_symbol() }
In the future, we can also imagine providing a compatibility
library that would replace EFL's internal APIs with a newer
version. This would let apps use new EFLs on platforms that
don't update fast enough.
I am now pushing this patch as an experiment to see what breaks,
but I expect no problem.
@feature
The current eo_add uses a (very useful) gcc extension that is only
available in gcc compatible compilers (e.g clang). Until this commit we
just temporarily ignored this fact. This adds a fallback implementation that
can be used interchangeably with the non portable one. This means that the
same binary can call either at any point in time and the code will work.
Breaks ABI.
It was temporarily eoid, change it to eo_self which is more
descriptive. In this process I also made it a macro to prepare
for the proposed changes on the ML for the fallback implementation
for compilers that don't support the compound statements returning
values gcc extension.
I found a way to keep eo_add() the way it was and gracefully degrade to
a portable (but not as fast) solution for compilers that don't support
the compound macros returning a value gnu extension: ({int a; a;}).
I'm reverting these changes now, and I'll introduce the fallback as soon
as I can.
This reverts commit b85bb37183.
Reverting this at Felipe's request following my email. There are many
things I strongly object to in this commit. I've touched the surface of
those on the ML (which doesn't work at the moment), though we need to
better discuss it.
The gist:
1. dlsym is a really bad hack that is not even needed.
2. I don't see why eo should even be aware of promises. It's not aware
of list, hash and etc.
3. The eolian changes were done wrong.
This should have been discussed and consulted before done, even if only
because of the amount of hacks it includes and the cross-domain (ecore,
eo and eolian) nature of it.
This reverts commit f9ba80ab33.
Imagine this. You have an object. You pass this object handle as a
message to another thread. Let's say it's not a UI object, so
something you might expect to be able to be accessed from multiple
threads. In order to keep the object alive you eo_ref() it when
placing the message on a queue and eo_unref() it once the message is
"done" in the other thread. If the original sender unref()ed the
object before the message is done, then the object will be destroyed
in the reciever thread. This is bad for objects "expecting" not to be
destroyed outside their owning thread.
This allows thius situation to be fixed. A constructor in a class of
an object can set up a delete interceptor. For example if we have a
"loop ownership" class you multi-ple-inherit from/use as a mixin. This
class will set up the interceptor to ensure that on destruction if
pthread_self() != owning loop thread id, then add object to "delete
me" queue on the owning loop and wake it up. the owning loop thread
will wake up and then process this queue and delete the queued objects
nicely and safely within the "owning context".
This can also be used in this same manner to defer deletion within a
loop "until later" in the same delete_me queue.
You can even use this as a caching mechanism for objects to prevernt
their actual destruction and instead place them in a cached area to be
picked from at a later date.
The uses are many for this and this is a basic building block for
future EFL features like generic messages where a message payload
could be an eo object and thus the above loop onwership issue can
happen and needs fixing.
This adds APIs, implementation, documentation (doxy reference) and tests.
@feature
Stefan Schmidt
Tom Hacohen
Cedric BAIL
Jean-Philippe Andre
Jean Guyomarc'h
Carsten Haitzler
Daniel Kolesa
Amitesh Singh
Felipe Magno de Almeida