file != NULL does not mean it's valid. Since Eina_File is
a basic eina type a magic check is still better than nothing.
It can avoid doing eina_file_dup() on a closed file for instance.
This "fixes" a crash in eina_file_close with invalid files.
Now I can go hunt the root cause...
In C we need this to make clear that we really do not accept parameters.
Found by the smatch source code matcher. I had run and fixed this before
but it seems to creep in again over time.
Brought up by running smatch. We have way to many of such things in tree though
to fix them all without annoying a lot of people. I will just stop here.
Summary:
Since eina_model was dropped some years ago.
Also a few other points where related stuff is just commented out.
Reviewers: iscaro, barbieri
Reviewed By: barbieri
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4442
@fix
Summary: add ARG_NONNULL to eina_log* APIs for Eina_Log_Domain * parameter that is always in use, can not be NULL.
Reviewers: cedric, Hermet, myoungwoon, NikaWhite
Reviewed By: NikaWhite
Subscribers: t.naumenko, jpeg
Differential Revision: https://phab.enlightenment.org/D4426
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Func _eina_file_win32_first_file try to find the first file in directory
but if any file not found the file handler stay open, and func will
return error. But in this case while handle is open impossible to do
any actions. For example call eina_file_ls for empty folder, func will
return error and fold folder open. And if we try to remove this folder
Windows only mark it to delete, and remove it after the process is
complete.
Solution: close handler in error case.
Summary:
fix warnings while generating documents
- end of file while inside a group (eina_util.h)
- missing title after \defgroup
- ignoring title "Ecore_Con_Lib_Group" that does not match old title
Reviewers: Hermet
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4420
Summary:
the new iterator represents the order from the elements of the original
iterator, elements where the filter callback return false will be
skipped.
The container of this iterator is the original iterator.
Test Plan: Just run `make check` there is a testcase
Reviewers: cedric, jpeg, raster, herdsman
Differential Revision: https://phab.enlightenment.org/D4417
Seems to me there is little benefit of inlining this function, but this
also had a pervert effect on Windows and C++ with some recent mingw
versions. Mingw failed its implementation of pthread_cleanup_pop(). It
does not compile when compiled in C++. There is a type mismatch that is
caught by the compiler, and everything goes nuts...
This made the EFL build fail because some files of ecore_win32 are C++
sources, and they require Eina... so this macro appears in a C++ code
indirectly, because of its inlining.
By removing the inlining, this build issue is fixed. Will also fix
builds of other programs that would have used Eina.h in their C++
programs :)
this will make a freeq bypass that is enabled by using valgrind or env
var not affect a freeq that has manually changed its queue count max
or mem max. these now become explicit deferred freeers.
this checks for clock_gettime + CLOCK_MONOTONIC or CLOCK_REALTIME at
evlog init to avoid a cmp+brang and l1 instr cache hit every get.
slightly less overhead when this is on.
this runs a 1000hz (or as best the kernel will allow) polling system
monitor thread that will logg the cpu frequencies of all cores (linux
only) as well as cpu usage per thread. this leads to much more
information able to be logged from an efl app (any efl app).
@feature
Summary: Add checking on NULL like in other API in module, to avoid segmentation fault
Reviewers: NikaWhite, cedric
Reviewed By: cedric
Subscribers: myoungwoon, jpeg
Differential Revision: https://phab.enlightenment.org/D4383
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
so i have been doing some profiling on my rpi3 ... and it seems
memcmp() is like the number one top used function - especially running
e in wayland compositor mode. it uses accoring to perf top about 9-15%
of samples (samples are not adding up to 100%). no - i cant seem to
get a call graph because all that happens is the whole kernel locks up
solid if i try, so i can only get the leaf node call stats. what
function was currently active at the sample time. memcmp is the
biggest by far. 2-3 times anything else.
13.47% libarmmem.so [.] memcmp
6.43% libevas.so.1.18.99 [.] _evas_render_phase1_object_pro
4.74% libevas.so.1.18.99 [.] evas_render_updates_internal.c
2.84% libeo.so.1.18.99 [.] _eo_obj_pointer_get
2.49% libevas.so.1.18.99 [.] evas_render_updates_internal_l
2.03% libpthread-2.24.so [.] pthread_getspecific
1.61% libeo.so.1.18.99 [.] efl_data_scope_get
1.60% libevas.so.1.18.99 [.] _evas_event_object_list_raw_in
1.54% libevas.so.1.18.99 [.] evas_object_smart_changed_get
1.32% libgcc_s.so.1 [.] __udivsi3
1.21% libevas.so.1.18.99 [.] evas_object_is_active
1.14% libc-2.24.so [.] malloc
0.96% libevas.so.1.18.99 [.] evas_render_mapped
0.85% libeo.so.1.18.99 [.] efl_isa
yeah. it's perf. it's sampling so not 100% accurate, but close to
"good enough" for the bigger stuff. so interestingly memcmp() is
actually in a special library/module (libarmmem.so) and is a REAL
function call. so doing memcmp's for small bits of memory ESPECIALLY
when we know their size in advance is not great. i am not sure our own
use of memcmp() is the actual culprit because even with this patch
memcmp still is right up there. we use it for stringshare which is
harder to remove as stringshare has variable sized memory blobs to
compare.
but the point remains - memcmp() is an ACTUAL function call. even on
x86 (i checked the assembly). and replacing it with a static inline
custom comparer is better. in fact i did that and benchmarked it as a
sample case for eina_tiler which has 4 ints (16 bytes) to compare
every time. i also compiled to assembly on x86 to inspect and make sure
things made sense.
the text color compare was just comparing 4 bytes as a color (an int
worth) which was silly to use memcmp on as it could just cast to an
int and do a == b. the map was a little more evil as it was 2 ptrs
plus 2 bitfields, but the way bitfields work means i can assume the
last byte is both bitfields combined. i can be a little more evil for
the rect tests as 4 ints compared is the same as comparing 2 long
longs (64bit types). yes. don't get pedantic. all platforms efl works
on work this way and this is a base assumption in efl and it's true
everywhere worth talking about.
yes - i tried __int128 too. it was not faster on x86 anyway and can't
compile on armv7. in my speed tests on x86-64, comparing 2 rects by
casting to a struct of 2 long long's and comparing just those is 70%
faster than comapring 4 ints. and the 2 long longs is 360% faster than
a memcmp. on arm (my rpi3) the long long is 12% faster than the 4 ints,
and it is 226% faster than a memcmp().
it'd be best if we didnt even have to compare at all, but with these
algorithms we do, so doing it faster is better.
we probably should nuke all the memcmp's we have that are not of large
bits of memory or variable sized bits of memory.
i set breakpoints for memcmp and found at least a chunk in efl. but
also it seems the vc4 driver was also doing it too. i have no idea how
much memory it was doing this to and it may ultimately be the biggest
culprit here, BUT we may as well reduce our overhead since i've found
this anyway. less "false positives" when hunting problems.
why am i doing this? i'm setting framerate hiccups. eg like we drop 3,
5 or 10 frames, then drop another bunch, then go back to smooth, then
this hiccup again. finding out WHAT is causing that hiccup is hard. i
can only SEE the hiccups on my rpi3 - not on x86. i am not so sure
it's cpufreq bouncing about as i've locked cpu to 600mhz and it still
happens. it's something else. maybe something we are polling? maybe
it's something in our drm/kms backend? maybe its in the vc4 drivers or
kernel parts? i have no idea. trying to hunt this is hard, but this is
important as this is something that possibly is affecting everyone but
other hw is fast enough to hide it...
in the meantime find and optimize what i find along the way.
@optimize
this adds eina_freeq api's for c land for deferring freeing of
pointers and can be used a s a simple copy & paste drop-in for free()
just to "do this later". the pointer will eveentually be freed as
eina_shutdown will free the main free queue and this will in turn free
everything in it. as long as the main lo0op keeps pumping things will
og on the queue and then be freed from it. free queues have limits so
if they get full they will clear out old pointers and free them so it
won't grow without bound. the default max is 1mb of data or 16384
items whichever limit is hit first and at that point the oldest item
will be freed to make room for the newest. the mainloop whenever it
finishes idle enterers will add an idler to spin and free while idle.
the sizes can be tuned and aruged about as to what defaults should be.
this also allows for better memory debugging too by being able to fill
freed memory with patterns if its small enough etc. etc.
@feature
following my commit for ecore_init(), do that for eina_init() as well,
sometimes it's hard to find the vars and their meaning without looking
at the code.
in eina_file we are using eina_hash, eina_hash is using eina_rbtree, so
we should ensure that rbtree is shutted down AFTER file is shutted down.
fix T4753
It's not because the bug with __builtin_prefetch is inside
clang/llvm that we must break the build for people who prefer it
over gcc. As soon as a non-broken version is out, the ifdef must
be either removed (and ask people to update their clang install)
or add a version check based on __clang_xxx__.
Compilation tested with clang 3.8.1 and gcc 6.2.1.
i see a speedup of about 8% over a series of list walking and freeing
functions given this change. it's a small speedup but still not too
shabby just for some prefetches thrown in. ymmv depending on memory
subsystem, memory speed itself, cpu and architecture.
@optimize
this allows you to portably use prefetch compiler builtins. this adds
EINA_PREFETCH(), EINA_PREFETCH_WRITE(), EINA_PREFETCH_NOCACHE() and
EINA_PREFETCH_NOCACHE_WRITE() macros to do this that are "nothing" if
your compiler doesnt support it. of course it also requires your
compielr compile instructions for your architecture and it can only do
so if the architecture it compiles for has these instructions, so be
aware.
@feat
this moves a lot of logic that is rare away from the linear/flat asm
path of code so we et fewer l1 cache misses when executing chuncks of
our code. this also reduces the code size and takes some funcs like in
eina_inline_lock_posix.x and makes them real functions to reduce code
size thus better l1 cache usage - only for new/free of locks.
spinlocks, semaphores etc. as these will have no advantage being
inlined but simply bloat out code size instead.
overall this actually reduces efl lib binary sizes 0.4%, so that's a
good sign.
this passes make check and i think i got it right... let me know if i
didn't. i'm also not sure i should just keep the static inlines and
not make the formerly static inline funcs full EAPI ones now... good q.
CPUs can be turned off after boot leading to a sparse mapping of core ids.
For example, if I turn off the first four cores on an exynos 5422 (these
are the low speed cores) then the high speed cores are still numbered 4-7
but there are only 4 cores present.
In that situation using affinity_core % num_cpus will prevent ever being
able to set affinity at all.
Just remove the pointless check and let the user set whatever core id they
want.
In a big.LITTLE ARM system cores can have different capabilities. This
gives an internal API that randomly returns the core id of any of the
system's fastest cores.
On systems where all cores are the same, it will return any available core.
If we don't have cpufreq support we just return 0
With MSYS1 or cygwin 1.5, or DOS console, the display is done by redirecting
stdout and al. So to change the colors, the Win32 API of the console must be
used.
On the contrary, the terminals based on mintty (like cygwin 1.8 terminal or MSYS2)
the redirection is done with pipes, so the Win32 API of the console does not
work when changing the colors and we can use the POSIX colors of printf.
This patch is fixing the eina code which alwayss use the Win32 API of the console
on Windows, even if mintty-based terminals are used
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.
Summary:
"/**" requires for doxygen, but one "*" is omitted for the reference
of eina_matrix3_multiply().
Reviewers: Hermet
Reviewed By: Hermet
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4266
Summary:
These macros allow you to define module informations like
author/description/version/license
e.g.
// Use "Name <email id>" or just "Name"
EINA_MODULE_AUTHOR("Enlightenment Community");
// Mention license
EINA_MODULE_LICENSE("GPL v2");
// What your module does
EINA_MODULE_DESCRIPTION("This is what this module does");
// Module version
EINA_MODULE_VERSION("0.1");
Now eina_modinfo can show these informations to users
$ eina_modinfo module.so
version: 0.1
description: Entry test
license: GPLv2
author: Enlightenment Community
@feature
Reviewers: cedric, tasn, raster, jpeg
Subscribers: seoz
Differential Revision: https://phab.enlightenment.org/D4257
eina_error_msg_get() must return NULL if an incorrect error is provided.
The XSI strerror_r() returns EINVAL when an invalid error is passed to
it, so we can end the function here. If we kept on, we would have tested
against the 'unknown_prefix' ("Unknown error ") which is implementation
defined, and registered a new error when the invalid error message
didn't match the 'unknown_prefix'. This new error message would have
been returned, which is not what we expected.
This case arised on Mac OS X where the 'unkwown prefix' is
"Unknown error: " instead of "Unknown error ".
It fixes eina test suite on Mac OS X.
Mac OS X does not support POSIX unnamed semaphores, only named
semaphores, which are persistant IPC: when the program exits,
and if semaphores where not released, they stay forever...
All EFL programs were "leaking" a semaphore, due to how
eina_log_monitor manages its resources. Therefore, after building
EFL a lot (which run eolian_gen, eolian_cxx, elua, edje_cc, ...)
we were not able to create any semaphore...
Now, we get rid of these semaphores and use Mac OS X's own
semaphores. Code is less cumbersome, and we don't have any
disavantage of the named semaphores.
Fixes T4423
@fix
So glibc has decided that readdir_r is hard to use safely and deprecated it
this summer. They recommand to use readdir, which was in the past unsafe to
use in a multi thread scenario, but is now on most system (and all system
we care, including our own implementation in evil). It is basically safe
as long the same DIRP is not accessed from another thread. This is true in
our code base, so we are fine to go with this.
For further reading: https://lwn.net/Articles/696474/
So actually there is quite a big issue with semaphores
on OSX. We use (named) POSIX semaphores, but this was
a (my) mistake... I'll fix it later...
The real issue is that named semaphore are persistants:
when the program dies, it stays alive. This is pretty
bad with eina_debug_monitor because we create a semaphore
we never release, due to a wild thread...
This leak of semaphores went unnoticed before commit
4a40ff95de because the
name of the semaphore was unique per process, and
overriden when another process was launched. This
was very bad, but saved us from overflowing the
semaphore pool. It is now overflowed pretty fast when
building a lot EFL, because of Eolian that runs A LOT!
So that's one problem that still needs to be fixed,
by using OSX' own semaphores (see T4423).
Another big issue, which is now fixed is that the
buffer in which we generated the semaphore ID was
too small, and therefore we were reduced to one shared
semaphore for a whole process... This buffer has been
now set to 31 characters, which seems to be the maximum
length of a semaphore ID.
So now things are better, but still with a deadly issue.
As pointed out in the mailing list, it was introduced in this release,
so it's better to remove the symbol instead of deprecating it.
People should use ETIMEDOUT directly.
So, first, the wrong strerror_r() was detected on
Mac OS X. Instead of using a complex set of macros
to try to detect which strerror_r() to use, when
it is defined, let the autotools handle that clerverness
for us.
we have some duplication of errors between Eina_Error and errno.h,
however we should use Eina_Error to extend the traditional errno.h
system.
then change eina_error_msg_register() and
eina_error_msg_static_register() to return a magic bit to state the
number was registered, and on other functions test this bit in order
to operate on registered values, otherwise fallback to errno.h, such
as strerror().
It also deprecates 2 clear duplicated errors:
- EINA_ERROR_OUT_OF_MEMORY -> ENOMEM
- EINA_ERROR_TIMEOUT -> ETIMEDOUT
There are two details when using strerror():
- old behavior did not return strings for non-error, such as
"Success" or "Unknown error ${N}"
- thread-safety issues: since we must be thread safe, then use
strerror_r() and eina_stringshare_add() that value, keeping a hash
of cached values
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.
This reverts commit d19cd4e63c.
This causes a SIGBUS error on OpenBSD when closing any application. As this
was safety patch only I will revert it for the 1.18 release and we can work
out what breaks OpenBSD here for 1.19
Fixes T4332
Without this I get errors from the clang compiler used on Travis for some OSX
builds:
../src/lib/eina/eina_inline_lock_posix.x:845:27: error: use of undeclared identifier 'getpid'
we don't give any debug or info if a module in a list fails to load.
we should at least offer debug info. do that. this fixes coverity
issue CID 1039687
fixes CID 1361219
if you had an env var a few gb in size or we had stuff in the last bit
of memory address space this might be an issue, but that won't happen.
@fix
fixes CID 1361220
in theory yes end minus start could be insanely huge or end be very
high in memory thus causing an overflow. this would have to be in the
last few bytes of memory space, so it never going to happen. and the
input from the env var has to be sane anyway as its user controlled.
@fix
the way eina does sempahores, they can NEVER be sensibly shared
cross-process portably. so enabling sharing is a pointless idea. in
fact some os's like openbsd check if the sempahore addres is in a
sharable mem region and deny init if it is not. on osx you dont use
shared memory but a sempahore name you share instead... and this is
not exposed thus it can't be shared either. if we did process sharable
semaphores we'd make shm segments and/or name them in a sharable way
were you can share the idenitifer of the shm segment and/or the offset
address or name from osx. but we don't, so making them
process-private is the right thing. sharable sempahores will need a
whole new api.
this also fixes osx naming to make the name pretty unguessable/private
and opened exclusive (or it fails) by using pid, sem counter, and 4
random numbers. it's not a security mechanism as the create will fail
if there is a clash. chances are low. we unlink before anyway. good
enough for osx for now.
@fix
Coverity reports that eina_safepointer_get returns a NULL promise here
(checked 20 out of 21 times). As eina_safepointer_get can return NULL,
we should check the validity of 'promise' here before trying to
derefernce it later.
Fixes Coverity CID1356625
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
there was a leak of elements on the itrator stack when the stack was
flushed still having some items on it, thus losing their pointers and
never freeing them.
@fix
I guess the overflow was badly handled. Fixing it by using
explicit int intermediate value.
Fixes CID 1356616 and 1356619:
Operands don't affect result
Logically dead code
so. on linux signals are delivered to the main process thread/loop.
thats' where signal handlers are set up and always run. this is sane.
it's predicatble. but of course this is not the same in bsd land.
there "just send the signal to any old thread and call the signal
handler there" seems to tbe the order of the day. this explains why
wer are losing sigchld signals in edje_cc - it's heavily threaded and
bsd is just randombly picking a thread to call it on.
this fixes that. in theory. i hope. i can't test, but putting it in to
share
@fix
This is a reccurring compatibility issue...
MAP_ANONYMOUS is not defined on OSX, but MAP_ANON is.
I know MAP_ANON is marked as deprecated in the Linux man
pages, but it has the benefit of being more portable.
This is heavily inspired from Eo_Id infrastructure. Main change
are that the lower bit are always guaranteed to be zero and ignored
by all function. Also it may be a little bit less efficient in some
case, but we will tune it once we have real life usage of it.
Eo won't be migrated for 1.18 to it as Eo_Id is deeply integrated
and it is quite risky to touch it so close from a freeze. This can
wait.
In case of failure within eina_lock_new() (posix), a
pthread_mutexattr_t would have been left in an initialized state,
without any deinitialization being called.
Consequences would have been implementation defined.
DragonFlyBSD has pthread_setname_np but no pthread_setaffinity_np;
we still need to include pthread_np though.
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Cancelling a promise will fulfill it but won't actually free the memory. This
memory is under custody of the owner, who must either call value_set or
error_set to finish it.
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);
The call to eina_promise_then steals the first ref'count, so it is
possible that the promise is freed after the eina_promise_then,
so we need to eina_promise_ref before eina_promise_then.
We do properly unref promise while calling all the then callback. There
is no need to check it a second time (which actually lead to a 100%
bad access).
T3759
Eina_Error is not passed by pointer anymore, which could cause invalid
pointer access in promise compositions (all and race).
Also added Eina_Promise* to prototypes.
this fixes T3638
@fix
a note... thanks so much to aerodynamik for spotting this. i'm rather
surprised coverity didn't spot this... unless someone said to "shut up
coverity you're wrong" and they should not have.
i also might have expected compilers to spot this too... and add a
warning.
anyway ... this was a seriously subtle bug that could have caused all
kinds of havoc in efl. keys that are different may be compared to be
the same. it could get ordering wrong and sorting thus maybe insert
keys that cannot be found anymore and oh so much more besides.
rthis replaces double a == double b with a macro that keeps a close
enough range using epsilon (which is the error range for a dobule).
this fixes T3245
this should fix T3245
this is basicall where we go double a == double b and due to precision
issues this may not always be right, but this means that the
equivalent now checks for "really close values" rather than perfectly
exact.
@fix
This is done on an attempt to permanently fix our Windows port. Windows
doesn't have MIN/MAX, so we should always do a ifndef/define in every
piece of code that use it. Of course we always forget and it take times
to notice and fix. We have over the year added it in many private
headers, but as the issue continue to raise again and again, I prefer
to get this fixed in our main header.
Added eina_promise_race function that composes multiple
promise objects into a new promise which is fulfilled
when one of the promises are fulfilled, or fails
when one of the promises have failed.
Add a way for users of the promise owner to get notified when a
promise progress is registered. Also added a convenience composition
function that creates a promise which is fulfilled when another
promise has a progress notification.
So it seems we are using Eina_Hash_Iterator quite a lot more than before.
This lead to a huge amount of alloc/free of Eina_Rbtree_Iterator that
was noticable in Enlightenment callgrind trace. This patch make it vanish
from the trace :-)
Fix value_set and error_set signatures which were receiving a
owner. They actually receive the promise and not the owner, this
caused wrong access to memory and were not visible by warnings because
the functions are casted.
This problem caused errors in which it seemed that promise had
actually error'ed when questioned it.
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.
xdg runtime dir is NOT a tmp dir in the normal sense. it's not world
writable nor world readable. only for the user. using
eina_environment_tmp_get() would imply that it is a regular tmp dir,
not a per-user private only runtime dir. that is something else
entirely.
@fix
Add a promise object to 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 {
@inout promise: Promise<int>;
}
}
}
}
Which will create the following API interface:
void foo_bar(Eo* obj, Eina_Promise** promise);
and a Eina_Promise_Owner for the implementation, like this:
void _foo_bar(Eo* obj, Private_Data* pdata, Eina_Promise_Owner* promise);
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
Add a promise object that will allows Eolian interface to include promises
as a way to have asynchronous value return and composibility.
To understand better, let see the coming usage in a .eo file:
class Foo {
methods {
bar {
params {
@inout promise: Promise<int>;
}
}
}
}
Which will create the following API interface:
void foo_bar(Eo* obj, Eina_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 automatically. So the user of this
function will treat it as a @out parameter, while the developer of the
function will treat it like a @inout parameter.
So, the user will use this function like this:
Eina_Promise* promise; // No need to instantiate
foo_bar(obj, &promise);
eina_promise_then(promise, callback);
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
Summary:
Use aditional temporary vector for intermedia results in case output vector
the same as target vector in functions:
eina_vector2_transform,
eina_vector2_homogeneous_direction_transform,
eina_vector3_cross_product,
eina_vector3_transform,
eina_vector3_homogeneous_direction_transform
It was in original version (in evas_vecN, module evas_3d_utils.h)
Enrich test suit for this case.
Reviewers: jpeg, cedric
Reviewed By: cedric
Differential Revision: https://phab.enlightenment.org/D3795
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
Cedric BAIL
Marcel Hollerbach
Jean-Philippe Andre
Stefan Schmidt
Bruno Dilly
Artem Popov
Gustavo Sverzut Barbieri
Vyacheslav Reutskiy
Jee-Yong Um
Carsten Haitzler
Jean Guyomarc'h
Derek Foreman
Jee-Yong Um
Vincent Torri
Andrii Kroitor
Amitesh Singh
Jean Guyomarc'h
Chris Michael
Felipe Magno de Almeida
Lauro Moura
Benjamin Jacobs
Larry Jr
Tom Hacohen
Jean Guyomarc'h
Boris Faure
Oleksandr Shcherbina