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
Ecore will now load "system modules" on ecore_init(). The "systemd"
module will use DBus to monitor localed, hostnamed and timedated and
add system events related to those changes.
If we have timerfd then we can set a timer with special features
(ABSTIME | CANCELON) to be notified if its offset to monotonic time
change, effectively this will alert us if user called settimeofday()
or similar method to change system time.
This code was inspired by Enlightenment's clock module.
- If we are supposed to be deleting an fd handler, let's use
g_source_remove_poll instead of g_source_add_poll ;)
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Call _ecore_pipe_unhandle() when you return from _ecore_pipe_read() or the fd will never be closed.
This fixed increasing numbers of fd handler issue when you call ecore_pipe_add/del repeatedly.
In that case, reusing ecore_pipe is recommended though.
Now, Ecore.h includes three new files:
- Ecore_Eo.h: Eo API functions (functions defines, enums, base id).
- Ecore_Legacy.h: contains the API functions related to objects
- Ecore_Common.h: common data (structs, enums...) + functions not
related to objects.
This phase is needed for the EFL 1.8 release to disable Eo APIs if we
consider it is not enough mature to be used by applications.
I don't really like this patch. I think it would be nicer to have mmap
been correctly detected when Evil or Exotic is there, but at this point
I don't feel at ease with configure.ac.
This fixes a mutex allocated on stack, a race on GCond initialization
and use of deprecated functions: g_mutex_new() and friends were
deprecated in glib 2.32.
That work clearly was possible thanks to Leandro. If you want more information
go to his blog : http://tia.mat.br/posts/async_io_with_coroutines/ .
The main difference with his implementation is more portable and not thread safe.
It does not have a custom swapcontext (would make sense as we don't need to save
the sigcontext) so it will be less fast. If people are ready to contribute asm
patch for that purpose I will be happy to apply them.
As for portability this code should work on all architecture we already support
thanks to a nice hack with setjmp/longjmp borowed from libcoroutine. We do use
Fiber for Windows support, but as 1.8 is completely borken in that regard, this
is theorical work only.
Thinks left to do :
- Eoify the API
- Documentation
- More tests
- Add support for coroutine in fd handler
- Add coroutine support to ecore_thread api
- Write some example
do not include Ecore_Input.h just to get Ecore_Window and Ecore_Getopt
to get handful typedefs.
NOTE: why do we have the #ifdefs around these predefs? At least GCC does not warn if we typedef twice the same thing (if they are identical)
SVN revision: 82499
Disabled by default, enable with --enable-audio
ALSA support is disabled as it is not there yet. Pulseaudio should work
though.
Support for .ogg and .wav is there as well (.mp3 is not)
Signed-off-by: Daniel Willmann <d.willmann@samsung.com>
SVN revision: 81000
Thanks to PrinceAMD (Deon Thomas) for bugging me to implement this,
then test and add a fix, now we can implement something similar to
"xterm -e" in terminology.
ECORE_GETOPT_ACTION_BREAK will allow generic options to behave the
same as GNU's --, breaking out of argument parsing logic.
SVN revision: 80619
Subject: [E-devel] [PATCH][Ecore] Fixes for invalid memory read issues
discovered by cppcheck
One more patch to fix issues discovered by cppcheck.
SVN revision: 80559
* remove the option, as it shouldn't really exist.
* keep code, as requested by Cedric, someone may fix it someday. And
the default is the DISABLED, as the enable was broken.
* Add instructions on how to solve the problem, if a brave folk is up
to it.
SVN revision: 80352
Subject: Re: Re: Re: [E-devel] [RFC] Virtual desktop window profile
I've attached 4th patch. May the 4th be with you.
ecore patch has been merged with efl and all files are based on r80123.
Thanks & Regards,
Gwanglim
------- Original Message -------
Sender : Daniel Juyung Seo<seojuyung2@gmail.com>
Date : 2012-12-04 01:55 (GMT+09:00)
Title : Re: Re: [E-devel] [RFC] Virtual desktop window profile
It looks ok to me.
Sorry but can you re-generate the patch according to the recent ecore
merge to efl single tree?
Daniel Juyung Seo (SeoZ)
On Thu, Nov 29, 2012 at 12:29 AM, Gwanglim Lee <gl77.lee@samsung.com>
wrote:
Dear Raster and Daniel Juyung Seo,
I've attached 3rd patches and test_config according to your reviews.
These are based on r79782.
[elementary & ecore]
1. "profile,set" -> "profile,changed" - done
2. spaces after EINA_LIST_FOREACH - done
3. variable type - keep
4. author - done
5. removing deprecated marking in patch - done
6. add elm_win_available_profiles_get to test_config for the debugging
purpose - done
7. check whether a given profile is present in an available profiles.
otherwise window profile will be one of the item
in available profiles. - newly added thing to the elm_win
8. merge with EO - done. :(
Any comments would be appreciated.
SVN revision: 80214