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.
we do not check any of success, failure or progress, so we must check
if they are valid before calling.
This fixed a bug in efl_net_dialer_tcp where it uses a null failure
cb and was SEGV.
Efl_Future actually work with weak reference. So you do not need to
set things to NULL, but you actually need to register the memory location
of the future with efl_future_use.
This would have forced who ever used future,none signal to manually
filter out event triggered by all the future beeing fullfiled and
disconnecting once they receive a value or are marked failed.
As discussed in the mailing list, many people will use worker threads
to execute blocking syscalls and mandating ecore_thread_check() for
voluntary preemption reduces the ecore_thread usefulness a lot.
A clear example is ecore_con usage of connect() and getaddrinfo() in
threads. If the connect timeout expires, the thread will be cancelled,
but it was blocked on syscalls and they will hang around for long
time. If the application exits, ecore will print an error saying it
can SEGV.
Then enable access to pthread_setcancelstate(PTHREAD_CANCEL_ENABLE)
via eina_thread_cancellable_set(EINA_TRUE), to pthread_cancel() via
eina_thread_cancel(), to pthread_cleanup_push()/pthread_cleanup_pop()
via EINA_THREAD_CLEANUP_PUSH()/EINA_THREAD_CLEANUP_POP() and so on.
Ecore threads will enforce non-cancellable threads on its own code,
but the user may decide to enable that and allow cancellation, that's
not an issue since ecore_thread now plays well and use cleanup
functions.
Ecore con connect/resolve make use of that and enable cancellable
state, efl_net_dialer_tcp benefits a lot from that.
A good comparison of the benefit is to run:
./src/examples/ecore/efl_io_copier_example tcp://google.com:1234 :stdout:
before and after. It will timeout after 30s and with this patch the
thread is gone, no ecore error is printed about possible SEGV.
This moved all the eoid tables, eoid lookup caches, generation count
information ad eo_isa cache into a TLS segment of memory that is
thread private. There is also a shared domain for EO objects that all
threads can access, but it has an added cost of a lock. This means
objects accessed outside the thread they were created in cannot be
accessed by another thread unless they are adopted in temporarily, or
create4d with the shared domain active at the time of creation. child
objects will use their parent object domain if created with a parent
object passed in. If you were accessing EO (EFL) objects across threads
before then this will actually now cause your code to fail as it was
invalid before to do this as no actual objects were threadsafe in EFL,
so this will force things to "fail early".
ecore_thread_main_loop_begin() and end() still work as this uses the
eo domain adoption features to temporarily adopt a domain during this
section and then return it when done.
This returns speed back to eo brining the overhead in my tests of
lookup for the elm genlist autobounce test in elementary from about
5-7% down to 2.5-2.6%. A steep drop.
This does not mean everything is perfect. Still to do are:
1. Tests in the test suite
2. Some API's to help for sending objects from thread to thread
3. Make the eo call cache TLS data to make it also safe
4. Look at other locks in eo and probably move them to TLS data
5. Make eo resolve and call wrappers that call the real method func do
recursive mutex wrapping of the given object IF it is a shared object
to provide threadsafety transparently for shared objects (but adding
some overhead as a result)
6. Test test est, and that is why this commit is going in now for wider
testing
7. Decide how to make this work with sending IPC (between threads)
8. Deciding what makes an object sendable (a sendable property in base?)
9. Deciding what makes an object shareable (a sharable property in base?)
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
while in a job we do not have the safety of eo holding us alive and
when we call back the user, he may have deleted the object, releasing
both the object and its private data that we're using.
then keep an extra reference, call the methods and release it.
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.
These interfaces allows generic operations on objects that can store
or provide data, such as a file or a buffer.
With well defined interfaces and events we can create code such as
Efl.Io.Copier, that will link a source with a destination and
progressively copy data as they appear.
it was silently ignoring the parent, which led me to hours trying to
investigate why my code wasn't working just to realize my parent
wasn't being assigned and refcounts were screwed.
This places the following behind beta:
- efl_quicklaunch_fallback
- efl_build_version_set
I don't think EFL_MAIN would have worked without BETA API support,
so no need to expose those for now.
@fix
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.
i've fixed almost all the eina init/shutdown pairs to do the right
thing now... except one (ecore_shutdown) with comment inline where
eo_shutdown is not called. if this is called we are in crash land.
this needs further inspection.
ecore_timer_del() checks a flag "inside_call" that can be
set before calling the timer cb... but it was never reset
to 0. So, all legacy timers would keep on ticking forever
and ever, until they return CANCEL.
Anyway, I find the distinction between eo_del and
ecore_timer_del very troubling. eo_del() should work
on a legacy timer. Ping @cedric. Maybe override eo_del()?
Fixes T3898
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).
evas 3d examples would always exit on a double free, since
EINA_INLIST_FREE was misused. Not surprising considering
it's different from EINA_LIST_FREE but has a similar name.
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
Clockid_t should be used as an opaque type. Some platform might want
to (and even do, e.g. DragonFlyBSD) declare clockid_t as an unsigned.
On such platform, testing the sign of clockid_t is never false, and
assigning it a negative value is an UB, which makes this code unlikely to
work as intended. Fixes black window on dragonfly!
Thanks to gcc for spotting this.
CC lib/ecore/lib_ecore_libecore_la-ecore_time.lo
In file included from ../src/lib/eina/Eina.h:215:0,
from lib/ecore/Ecore.h:304,
from lib/ecore/ecore_time.c:18:
lib/ecore/ecore_time.c: In function 'ecore_time_get':
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Turns out there is no PRI?SIGATOMIC in the C99 standard. Work around
that by deducing the effective integer type by comparing the
SIG_ATOMIC_MAX with integers *MAX.
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
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 lets me narrow down the remaining cases of pointers across the EFL.
The void pointers will later need to be reevaluated on per-case basis and
replaced appropriately where possible/feasible.
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.
Complex types (i.e. list, array, hash, accessor etc.) now do not require
pointers with them anymore (the pointer is implied) and the same goes for
class handles. Eolian now explicitly disallows creating pointers to these
as well. This is the first part of the work to remove pointers from Eolian
completely, with the goal of simplifying the DSL (higher level) and therefore
making it easier for bindings (as well as easier API usage).
@feature
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.
This allow you to monitor fd and get notification using Eo events. I
have not implemented the buffered read as used by X. I think that if
this is useful, we should just do another class to handle bufferred fd.
This reverts commit a13570c17c.
This doesn't really fix the problem which is hidden by eo capability to not
crash on bad unref. With legacy API you are allowed to do a ecore_timer_del
and also return EINA_FALSE. In that case you have a double eo_del (which is
luckily protected) and a double free (that is not). It does crash on the
double free, but the issue is a lifecycle issue. Will bring a better patch
for this.
Summary:
object_find is more generic, so other mechanisms can also reuse the
code.
The object itself has to support the function, so there is no need for
eo_isa which would have a negative performance impact.
The base class implementation calls interface_get on the parent, so a
override of the function can just call the super function to continue in
the recursion.
Test Plan: just run the eo test suite
Reviewers: raster, tasn, jpeg
Reviewed By: tasn, jpeg
Subscribers: felipealmeida, netstar, cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D3909
this means that on loop_get on any obj as long as its a child of a
loop obj... it'll retunr that loop now. it will work. no more code
needed.
we can shortcut this with ui/gfx objects returning the mainloop
singletone.
so i've been doing some debugging and having a mem debugger that
preloads and tracks allocs means you need locks, but locks can do
nasty things after forks + threads.... esp if threads held locks.
this allows mem debugging with preloads easily and doesn't muck things
up.
This fixes a crash in ecore_init, calling a weak function from
libefl that was resolved to NULL.
So, here's a fun thing happening with GCC < 5.3. Since a1a506e13e
all EOAPI and EO class_get() functions are weak symbols. This means
that all APIs inside libefl.so are weak.
As a result, gcc linker with --as-needed skipped linking to libefl
since not a single strong symbol from libefl was required by
libecore. This is actually a bug in gcc linker since we do in fact
use symbols from libefl, just weak ones.
GCC 5.3 seems to be fixed, so people with GCC 5.3+ will not
experience any build/runtime issue. The current patch is
a workaround that bug, by artifically creating a strong symbol
required by ecore.
Other libraries than ecore might also need to call
__efl_internal_init, if they end up not being linked to libefl.
Add ecore_thread_promise_run function that returns a Promise
and runs function in another thread which you can set the
value on a Eina_Promise_Owner.
Eina_Promise* promise;
Ecore_Thread* thread = ecore_thread_promise_run
( &function_heavy, &cancellation_function, private_data,
sizeof(ValueType), &promise);
This calls function_heavy on another thread and returns
the Ecore_Thread and a Eina_Promise as an out-parameter.
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
this inits a new vpath object and adds it at priority 0 to the vpath
manager so you can use the vpath manager to create vpath file objects
and look things up.
@feature
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.
Add a promise object that allows Eolian interface to include promises
as a way to have asynchronous value return and composibility.
The usage is like this in a .eo file:
class Foo {
methods {
bar {
params {
promise: Promise<int>;
}
}
}
}
Which will create the following API interface:
void foo_bar(Ecore_Promise** promise);
and the equivalent declaration for implementation.
However, the API function will instantiate the Promise for the
user and the implementer of the class.
Summary:
When glib support is enabled (HAVE_GLIB), _ecore_glib_init()
was always reserving resources. However, its counterpart may not
be called when:
- glib is not always integrated and
- when a user didn't explicitly required the integration.
Calling _ecore_glib_init() within the request code will cause the
resources to be reserved only when the integration with glib is
required and furthermore guarantees that resources always have a
chance to be released.
Reviewers: cedric, raster
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D3749
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
I just ran my script (email to follow) to migrate all of the EFL
automatically. This commit is *only* the automatic conversion, so it can
be easily reverted and re-run.
Moved the Ecore.Time @extern struct to Efl lib and defined it as
specified in C specification for struct tm. Thus, bindings can be
automatically generated for where struct tm is used.
Move Ecore_Pos_Map from Ecore_Common.h to ecore_types.eot.
Give it the namespaced Eolian name "Ecore_Pos_Map" to follow the
standards.
Update documentation to refer to Ecore_Pos_Map instead of its previous
enum definition "_Ecore_Pos_Map".
Create the file ecore_types.eot to hold common types related with Ecore.
Add Ecore.Time as an external type to ecore_types.eot.
This type is intended to be a alias to struct tm (from time.h).
That way .eo files have a standard way to reference it.
Each language should manually bind it.
Summary:
- EINA_MAIN_LOOP_CHECK_RETURN should be called before ecore lock
because this may return without ecore_unlock.
- remove EINA_UNLIKELY(!eina_main_loop_is()) which is redundant.
Reviewers: jpeg, jaehwan, cedric, raster
Reviewed By: raster
Subscribers: raster, conr2d, cedric, jpeg
Projects: #efl
Differential Revision: https://phab.enlightenment.org/D3541
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
To configure efl sources with bindings to use in nodejs add ––with-js=nodejs in configure flags to generate node files
$ configure --with-js=nodejs
and compile normally with:
$ make
$ make install
To use, you have to require efl:
efl = require('efl')
The bindings is divided in two parts: generated and manually
written. The generation uses the Eolian library for parsing Eo files
and generate C++ code that is compiled against V8 interpreter library
to create a efl.node file that can be required in a node.js instance.
@feature
Summary:
- When Ecore_Task_Cb is not set, _ecore_idle_exiter_constructor
returns without _ecore_unlock(), and remains to be locked.
Reviewers: jpeg
Reviewed By: jpeg
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D3424
This could lead to some very long and unexpected pause as the timeout passed
to eina_condition_timedwait was passed as a absolute time instead of relative.
Hopefully we don't build rocket.
As reported by vtorri, sometimes ecore_exe on win32 will encounter double
free issues. This was because the variable was freed, but not set to NULL
as expected by the cleanup function.
Fixes T2675
@fix
This fixes the CPU to be usedat 100% for each thread in ecore_exe. This
is obviously not an ideal fix and will be improved in the future.
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Output and error threads could not read all the data sent by the child.
Based on a patch by Guillaume Friloux
@fix
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
When fd handler is deleted by ECORE_CALLBACK_CANCEL, _ecore_main_fdh_poll_del() is not called.
So fd still exists in epoll's event pool.
Reviewers: raster, seoz, woohyun, Hermet, cedric
Reviewed By: cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D3131
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Coverity was complaining about a possible integer overflow. This isn't
actually possible, but coverity has no way to know that because we were
in fact using a too big of a type. I fixed it to be the right type so
now everything should work.
CID 98384
@fix
With -DDEBUG, we can see an error message, like:
ERR: You are calling _ecore_lock() from outside of the main loop
threads in lib/ecore/ecore_private at line 306
Looking at the code shows that ecore_lock fails immediately if
thread debugging is enabled, but ecore_unlock does not, so the
value _ecore_main_lock_count could go below 0.
This is not very important as the value is never used.
The correct way of disposing of an object in a failed finalisation is to
return NULL, not to delete it.
Also, since the destructor is already called when the object is deleted
anyway, there's no point in having cleanup code in the finalizer too.
@fix
this will cause animators to be more accurate now with timing coming
from a dedicated thread whose only reason in life is to trigger timed
wakeups. the wakeup time is even adjusted with fmod to the exact
frametime slot that is expected
This is another cleanup in perparation for the Eo stable release.
This is no longer needed thanks to the proper error reporting with
eo_constructor()'s new return value.
The finalizer change cleans it up a bit so it catches more cases/issues.
This also means that the finalizer cleans up the object in all cases,
and not only some.
@feature.
Instead of "@in type name;" we now use "@in name: type;". This change
is done because of consistency with the rest of Eolian; pretty much
every other part of Eolian syntax uses the latter form.
This is a big breaking change in the .eo format, so please update your
.eo files accordingly and compile Elementary together with the EFL.
@feature
if select gets interrupted it just waits again from the start because
it uses loop time not "now" time. this is wrong and makes timeout
waits possibly hang if enough things interrupt select without reading
data. this fixes that.
@fix
When this function fails to get the interval value, it should return -1.0.
Currently, the value can be integer(-1.0 has an Error).
Maybe it should be fixed.
@fix
Summary:
... to simply invoke `_ecore_main_fd_handler_add()`. The only difference appears to be the former sets `->file` to `EINA_TRUE`. So, we add that as a parameter.
You can consider this patch, and any other contributions I make to enlightenment, to be under the terms of whatever open source license governs that particular project, or at your option, the MIT license. Basically, if I'm uploading patches here, it's because I want them to be useful.
Test Plan: Should be pretty straightforward. I am in the process of doing a compile check.
Reviewers: #efl
Projects: #efl
Differential Revision: https://phab.enlightenment.org/D2302
if you fork and even if you do ecore_fork_reset() a thread calling
ecore_main_loop_thread_safe_call_async(0 for example eill end up
resetting the mainloop thread id to itself (a non mainlopo thread) via
calling eina_main_loop_is() since pid changed. there is little point
in doing this so remove the pid tracking from eina and ensure mainloop
thread id is updated in ecore's fork reset.
@fix
This enable the possibility to block the main loop until a
specific thread is done. It may trigger still process ending
of other thread during that function call, but not any other
type of event (timer, animator, idler, ... are all ignored).
Previous beizer cubic finds t value approximately.
In this sequence, there were 2 problems.
1. Previous guess_t value should be passed to differential equation to get the more accurate t value.
2. Guessing time count is not enough. I found 6 is enough time to get the t value experimentally. Previously it just tried 4 times on the other hand.
@fix
0.99.0 removed the OnLowBattery property and added the per-device WarningLevel property. this requires what will effectively be a full rewrite of the module to track all the power levels of all the attached batteries and set the ecore power level somehow based on a combination of their levels
since I have no desire to spend any more hours working on and debugging this module which is based on a known-unstable api, I'm making it disable itself if it detects a version >= 0.99.0. hopefully someone will decide to maintain both this and eldbus in the future so that we can more accurately track upstream when they make changes to these things
ref T1908
ref T1909
The previous compuation is totally wrong.
Even it doesn't work correctly.
(I have no idea what the orignal author was thinking?)
Here we just need a simple and clear fomular to get the current progress frame.
If i'm wrong, please ping me.
@fix
Summary: This commit adds the actual code to the function, which
returns the 'in_main_loop' variable so that we can detect if the
ecore_main_loop is actually running.
NB: Will be needed for new eldbus API function (yet to add).
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: This commit adds a new function 'ecore_main_loop_nested_get'
so that we can detect if the ecore_main_loop is running.
NB: This is going to be needed for a new eldbus function that we have
to add in order to handle a use-case on the Wayland side. Spoke with
cedric for a while wrt to all this, and he gave it his 'ok' ;)
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
These APIs were not meant to be exposed so it is not recommended to
use them out side of EFL. We had to expose them to use them between
EFL libraries. (Talked with Raster)
CreateProcess() has a flags parameter which is being passed
"run_pri | CREATE_SUSPENDED".
The issue lies in the value of run_pri. It is best explained by the
following code somewhere else in the file:
switch (run_pri)
{
case IDLE_PRIORITY_CLASS:
return ECORE_EXE_WIN32_PRIORITY_IDLE;
The run_pri variable is supposed to store a value from the win32 API while
it was used to store one from the ecore API.
If I recall correctly, the windows one is equal to 32 and the ecore one to
9999. Meaning 9999 ended up used as flags so let's have a look at what that
actually enabled; the reference is "Process Creation Flags" from MSDN
http://msdn.microsoft.com/en-us/library/ms684863%28v=vs.85%29.aspx .
9999 gives 0x0000270F and this matches
DEBUG_PROCESS | DETACHED_PROCESS | DEBUG_ONLY_THIS_PROCESS
| CREATE_SUSPENDED | CREATE_NEW_PROCESS_GROUP | CREATE_SEPARATE_WOW_VDM
| CREATE_UNICODE_ENVIRONMENT | <0x00002000 matches nothing>
Matches nothing? Weird. Well, maybe. Except that I stumbled upon this define
in the mingw-w64 headers:
#define CREATE_FORCEDOS 0x2000
Mingw-w64 only has a #define, Wine has nothing (they don't do DOS anyway),
but ReactOS has some code about it:
https://git.reactos.org/?p=reactos.git;a=blob;f=reactos/dll/win32/kernel32/client/proc.c;hb=f60941f8dc775427af04eb0a3c3e4d38160c7641#l3007
Overall the actual set of flags probably made very little sense and wasn't
working very well. :)
I also noticed the following in the mingw-w64 headers:
#define INHERIT_CALLER_PRIORITY 0x20000
This should be a better match for what seemed to be the original intent of
inheriting the priority. I haven't tested it and it's only documented on
MSDN for Windows CE and similar so I'm really not sure about what it does.
MSDN however mentions that the child processes will have at most the
"normal" priority by default (same as its parent if the parent has less
than the default one) but I'm under the impression a process can raise its
own priority level... Anyway, "NORMAL_PRIORITY_CLASS" will do for now.
With this change and a couple others, elementary's theme builds properly
on Windows (_on_ Windows). I'll assess the usefulness of the other changes
in my tree over the next few days.
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Some parts of the API documentation where not compiled at all by doxygen
because of missing '@{' and '@}' tags. This commit adds the missing tags
in Ecore_Getopt.h, Ecore_Con_Eet.h, and Ecore_IMF.h headers.
Before this change eo_add() used to create an object with 1 ref, and if
the object had a parent, a second ref.
Now, eo_add() always returns an object with 1 ref, and eo_add_ref()
preserves the old behaviour (for bindings).
eo_unref now un-parents if refcount is 0, and eo_del() is an alias for
eo_unref (will change to be a way to ensure an object is dead and goes
to zombie-land even if still refed).
While some docs have been added for these nobody added them to the
main ecore page. Which in turn makes them invisible for people reading
our docs.
I found three ecore family members to not even having a brief group
description: cocoa, pslight and sdl.
Would be good to get some basic docs in for them.
before trying to use it
eo_data_scope_get Could return NULL if it does not find valid
ecore_timer_data on this object. We should check that return before
just Assuming that timer data is valid.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This is the first step towards splitting it nicely. This fixes
compilation on windows (or so it seems from my testing) and takes out
all the platform specific code (posix included) out of the main source
file.
This should fix the dumb way it was split until now (everything was redundant).
Now we just reimplement the parts we need to reimplement and the rest is shared.
The win32 code is called from within the normal code.
It's as wrong as the other commit which TAsn already reverted.
This needs a fix elsewhere, particularly in the functions that
use arg_val.
This reverts commit ab53900364.
@fix
this fixes a long standing issue where a suspended animator still is
waking up as originally suspended animators were expected to hang out
for a small time. as e's comp uses a suspended animator, this is a
problem as it causes continual wakupes every single frame (60hz or so)
with this suspended animator. this fixes that and accounts for
suspended animators with tick begin/end
@feature
this allows you to set the ecore loop time. only useful in trying to
get hyper-accurate frame timings from sources when doin a custom tick
source.
this adjusts ecore loop time very slightlye tp be the "Exact" timepoint
when then animator timer, if timer is used, should have gone off. this
should make animations more precise.
@feature
mmhhmm, missing @ Constructor tag, bad for the bindings,
maybe we must split animator and timeline into 2 classes,
maybe support callback hot swaping ...
This reverts commit ec4ffb86d6.
Summary:
- use defauld constructor instead of custom one.
- we don't allow construction of an animator with a NULL callback function,
this is checked in overriden eo_finalize.
- we don't support changing this callback once the object is created,
such calls will call ERR() and return.
see 46a78e8c and f92e5d50 for eo_add_custom() -> eo_add() details
Reviewers: tasn
Reviewed By: tasn
CC: cedric
Differential Revision: https://phab.enlightenment.org/D1113
this fixes T1341. also it removes the pointless return value from
these two functions as the return is never used. also the ifdef in
ecore_main.c seemed wrong as it wasd using fcntl not execvp but the
ifdef was for execvp. this just never was discovered, so it's slid
under the hood for a long time.
Summary:
Applications are stuck when handler of pipe made nested loop.
In the nested loop, _ecore_pipe_read() tried to read new data based on previous information which is not cleared yet.
Spotted by gyuyoung.kim, sy302.park.
Related webkit bug is https://bugs.webkit.org/show_bug.cgi?id=129294
Reviewers: cedric, seoz, raster
CC: seoz, cedric
Differential Revision: https://phab.enlightenment.org/D790
Summary:
Changed uses of EINA_MAIN_LOOP_CHECK_RETURN for EINA_MAIN_LOOP_CHECK_RETURN_VAL
for functions that doesn't have void return types.
These only error out when compiling with --with-profile=debug
@fixed
Reviewers: raster, cedric, smohanty
CC: cedric
Differential Revision: https://phab.enlightenment.org/D765
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.
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.
This patch will detect how many more times ecore_init was called
during initialization and use that as a threshold to do a clean shutdown.
It is a necessary evil as we do have ecore module that will initialize
eldbus that will then reinit ecore_init from within ecore_init and without
a chance for the application to act on it.
I also reenable a test to make sure we will catch earlier this kind of issue.
positional arguments must appear at the end of the description array
(after the last option) and should have a metavar set and not have
shortname or longname. Simple, elegant and fit :-)
There is a new function to parse the positional arguments,
ecore_getopt_parse_positional() because we may want to not try to
parse them in the case of a quit-option such as --help, --license,
--copyright, --version or some user-defined action. This avoids us
producing errors of missing positional arguments when printing help
and adds some flexibility as well.
This should make Tasn happy :-)
Summary: Adding an option to use a cubic-bezier curve in edje transitions.
Reviewers: Sachiel, cedric, raster
Reviewed By: raster
CC: raster
Differential Revision: https://phab.enlightenment.org/D319
When the ecore_animator_source_set() is called with different sources repeatedly, sometimes internal timer is not deleted and this leads animator misbehavior.
Especially when the source is changed from ECORE_ANIMATOR_SOURCE_TIMER to ECORE_ANIMATOR_SOURCE_CUSTOM before the SOURCE_TIMER's internal timer is deleted, this problem occurs.
In this case, even though _end_tick() is called in ecore_animator_source_set(), the SOURCE_TIMER's timer is not deleted because the source is already changed to CUSTOM.
So we should delete the internal timer in _end_tick() in all cases.
Summary:
Function returns boolean value, docs said it can return int.
I had fixed that.
Reviewers: cedric, raster
Reviewed By: raster
CC: cedric
Differential Revision: https://phab.enlightenment.org/D342
time 0
for ECORE_EVENT_SYSTEM_TIMEDATE_CHANGED we use a timerfd on linux (and
also support talking to systemd) to detet time/date changes. the
timerfd was set up to go off at the absolute time of 0. since that is
almost always... in the past.. lets set a REAL time in the future.
(almost end of time)
This reverts commit 1714fe93f4.
We actually want this type, it makes things clearer.
Conflicts:
src/tests/eo/function_overrides/function_overrides_inherit2.c
src/tests/eo/function_overrides/function_overrides_simple.c
src/tests/eo/suite/eo_test_class_simple.c
Cedric BAIL
Derek Foreman
Marcel Hollerbach
Guilherme Iscaro
Jean-Philippe Andre
Tom Hacohen
Jaehwan Kim
Gustavo Sverzut Barbieri
Carsten Haitzler
Vitor Sousa
Ivan Furs
Vincent Torri
Felipe Magno de Almeida
Lauro Moura
Benjamin Jacobs
Daniel Kolesa
Jean Guyomarc'h
Jean Guyomarc'h
Stefan Schmidt
Daniel Zaoui
Mike Blumenkrantz
Sung-Taek Hong
Vincent Torri
Shinwoo Kim
Srivardhan Hebbar
Hosang Kim
Amitesh Singh
ChunEon Park
Ji-Youn Park
ChunEon Park
Vinícius dos Santos Oliveira
Vincent Torri
Conrad Meyer
Stefan Schmidt
Nicolas Aguirre
Andrii Kroitor
Guillaume Friloux
michelle legrand
Chris Michael
Vasyl Vavrychuk
Jérémy Zurcher
Daniel Juyung Seo
Adrien Nader
Pierre Le Magourou
Daniel Kolesa
Vincent Torri
Ryuan Choi
Yossi Kantor
Cedric Bail
Yakov Goldberg
Daniel Kolesa
Jihoon Kim
Cedric BAIL
Cedric BAIL
Otavio Pontes
Mariusz Grzegorczyk