Not sure _ecore_fd_valid() is all that useful anymore, as the
commit that introduced it said it would be removed "before release"
a long time ago - it's a debug assist that probably doesn't need
to be in release builds.
(I'm counting syscalls on rpi3 - still, calling this an optimization
seems like a bit of a stretch.)
Built on top of the new 'postponed' free queue, the short-lived
strings API allows users to return new strings without caring
about freeing them. EFL main loop will do this automatically for
them you at a later point in time (at the end of an iteration).
The APIs provided will either duplicate (copy) or more generally
steal an existing string (char *, stringshare, tmpstr, strbuf),
taking ownership of it and controling its lifetime. Those strings
can then be safely returned by an API. From a user point of view,
those strings must be considered like simple const char *, ie.
no need to free() them and their validity is limited to the
local scope.
There is no function to remove such a string from the freeq.
The short lived strings API is not thread-safe: do not send a
short-lived object from one thread to another.
@feature
The end of time is much closer than you think. it_value.tv_sec is
a signed 32-bit number on 32-bit machines. Using a negative tv_sec
causes timerfd_settime() to fail.
otherwise we are leaking a eina list.
This was discovered while running the elm_suite with CK_FORK=no, since
ecore and eina are init´ed and shutdown´ed, after the shutdown this list
points to freeed memory pools. So in the next testcase the list is
invalid and crashes. This fixes it with freeing the list on shutdown.
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
Efl.Object.event_callback_call no longer calls legacy smart callbacks;
calling only event callbacks registered with the given event description
pointer.
Create the method Efl.Object.event_callback_legacy_call to inherit the old
behavior from Efl.Object.event_callback_call, calling both Efl.Object events
and legacy smart callbacks.
Update all other files accordingly in order to still supply legacy
callbacks while they are necessary.
in theory another libc call could overwrite errno between select
exiting and errno being used for errors. be paranoid. i know of no
real bug that this causes though.
The original idea behind knowing the app's version of EFL is not
a great story. It comes from the fact that some bugs exist in
earlier versions of EFL, and some things need to be fixed. But
those fixes may break behaviour for older apps. This patch is
opening the way to the slippery slope of bug compatibility.
Unfortunately this is a requirement if we want to be able to move
forward and not break apps when we fix bugs (behaviour or ABI).
I hope we will not need to implement too many (if any) workaround
such issues. For now, this will only be used as debugging info.
EFL_MAIN() and ELM_MAIN() will both set the app's EFL version
automatically at startup time. Some internal helpers can be added
later to check how the app build-time and run-time version of
EFL differ.
@feature
Note: this is both @class and @property. Hope that's ok for
all bindings.
This returns same as ecore_main_loop_get() (which now uses the eo
api instead).
Ping @cedric (so he can check this patch).
On Solaris, this header is necessary for finite(). Instead of including it
if the sun compiler is used, include it if it exists. This fixes a warning
if gcc is used on Solaris
The bug came from the fact we need to handle the destruction of the
main loop which destroy the underlying timer. The event handler that
catch the destruction of the timer can not make the difference between
eo_del call from the timeout code and eo_del from the main loop
destruction. By removing the event handler, the double free is properly
avoided.
As we add more object in the main loop, they can't live in the top
namespace as they make little sense there (Efl.Fd !). For coherence,
everyone should in the loop namespace, so move timer there.
Now when dealing with pointer types, we will not get pointer to
pointer semantics in callbacks and eina_promise_owner_value_set
for Eina_Promise.
It will work as expected:
Eina_Promise_Owner* promise = eina_promise_add();
void* p = malloc(sizeof(T));
eina_promise_owner_value_set(promise, p, &free);
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.
this is an args event. right now we don't use it, but this should be
done by some of the setup/init of an app and then produce an args
event. the idea would be that this can be used by single-instance apps
like web browsers, terminology to treat launch as an event.
Previously events used to use class name as a prefix and ignored eo_prefix
when specified. This is no longer the case. Events follow eo_prefix by default
now. In order to get around this for classes where this is undesirable, a new
field event_prefix was added which takes priority over eo_prefix. If neither
is specified, class name is used like previously.
@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.
So ecore main loop does restart everything with an main loop shutdown
and init when it detect a bad fd. This can happen if you del a fd after
you have destroyed it. Something terminology is doing (and should be
legal), but that then ended up with a main loop with no event handler
registered and the process was looking like stuck with nothing happening.