The first branch is the POSIX-compliant one and the one that
should always be taken; __USE_MISC is an unrelated glibc-specific
macro so the code was not being used on non-glibc Linux systems
even though it should be.
All these branches are Linux-specific, so there is no legacy
code to worry about, even if it was actually useful at some point
in history.
what happened here is that people passed private data with a reference
to the object. Which is kind of a bad idea, as in some unthought of
conditions, events are forgot, which results in freeed memory beeing
accessed. This way its at least a error.
Summary:
Patch from a series of patches to rename EAPI symbols to specific
library DSOs.
= The Rationale =
This patch is from a series of patches to rename EAPI symbols to
specific library DSOs.
EAPI was designed to be able to pass
`__attribute__ ((visibility ("default")))` for symbols with
GCC, which would mean that even if -fvisibility=hidden was used
when compiling the library, the needed symbols would get exported.
MSVC __almost__ works like GCC (or mingw) in which you can
declare everything as export and it will just work (slower, but
it will work). But there's a caveat: global variables will not
work the same way for MSVC, but works for mingw and GCC.
For global variables (as opposed to functions), MSVC requires
correct DSO visibility for MSVC: instead of declaring a symbol as
export for everything, you need to declare it as import when
importing from another DSO and export when defining it locally.
With current EAPI definitions, we get the following example
working in mingw and MSVC (observe it doesn't define any global
variables as exported symbols).
Example 1:
dll1:
```
EAPI void foo(void);
EAPI void bar()
{
foo();
}
```
dll2:
```
EAPI void foo()
{
printf ("foo\n");
}
```
This works fine with API defined as __declspec(dllexport) in both
cases and for gcc defining as
`__atttribute__((visibility("default")))`.
However, the following:
Example 2:
dll1:
```
EAPI extern int foo;
EAPI void foobar(void);
EAPI void bar()
{
foo = 5;
foobar();
}
```
dll2:
```
EAPI int foo = 0;
EAPI void foobar()
{
printf ("foo %d\n", foo);
}
```
This will work on mingw but will not work for MSVC. And that's why
LIBAPI is the only solution that works for MSVC.
Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com>
Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev>
Reviewers: vtorri, woohyun, lucas, jptiz
Reviewed By: vtorri, lucas
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12210
Summary:
Add definition for EAPI_WEAK because this macro will be needed when we
change how Eolian generates import/export symbols for the Eio library.
= The Rationale =
This patch is from a series of patches to rename EAPI symbols to
specific library DSOs.
EAPI was designed to be able to pass
`__attribute__ ((visibility ("default")))` for symbols with
GCC, which would mean that even if -fvisibility=hidden was used
when compiling the library, the needed symbols would get exported.
MSVC __almost__ works like GCC (or mingw) in which you can
declare everything as export and it will just work (slower, but
it will work). But there's a caveat: global variables will not
work the same way for MSVC, but works for mingw and GCC.
For global variables (as opposed to functions), MSVC requires
correct DSO visibility for MSVC: instead of declaring a symbol as
export for everything, you need to declare it as import when
importing from another DSO and export when defining it locally.
With current EAPI definitions, we get the following example
working in mingw and MSVC (observe it doesn't define any global
variables as exported symbols).
Example 1:
dll1:
```
EAPI void foo(void);
EAPI void bar()
{
foo();
}
```
dll2:
```
EAPI void foo()
{
printf ("foo\n");
}
```
This works fine with API defined as __declspec(dllexport) in both
cases and for gcc defining as
`__atttribute__((visibility("default")))`.
However, the following:
Example 2:
dll1:
```
EAPI extern int foo;
EAPI void foobar(void);
EAPI void bar()
{
foo = 5;
foobar();
}
```
dll2:
```
EAPI int foo = 0;
EAPI void foobar()
{
printf ("foo %d\n", foo);
}
```
This will work on mingw but will not work for MSVC. And that's why
LIBAPI is the only solution that works for MSVC.
Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com>
Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev>
Reviewers: jptiz, lucas, vtorri, woohyun
Reviewed By: vtorri
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12201
Summary: I found wrong API reference group name in mapbuf, Evas, Eet, Eina, Eio and fixed them.
Test Plan: API reference documentation modification only
Reviewers: segfaultxavi, stefan_schmidt
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12052
these structs should not be used, but rather the builtin types that
exist for it.
Reviewed-by: Felipe Magno de Almeida <felipe@expertisesolutions.com.br>
Differential Revision: https://phab.enlightenment.org/D11742
libraries are split into deps, external deps, and pub deps.
Evas engines are refactored to use the predefined engine deps.
this is preparation work for efl-one.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11806
efreet_mime and efreet_trash are now included in libefreet.so. There are
compatible libs for libefreet_mime.so libefreet_trash.so, which simple
drag in libefreet.so. .pc files also are in place for compatibility.
efreet_init & shutdown now initializes and shutdowns trash and mime.
The old init functions now simply call efreet_init, efreet_init will
then init the trash or mime libs.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11807
Summary: EAPI must be defined to dllexport when building DLL, and to dllimport when using these DLL. To achieve this, define EFL_BUILD for each library and module, and set DLL_EXPORT unconditionally. Static library are and will be not supported
Test Plan: compilation
Reviewers: zmike, raster, jptiz
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11834
They have been known to crash some old compilers and have
severe performance penalties on non-power-of-two architectures
like the Chitauri 13-bit processors.
Tabs also cause eye strain, vomits, brain tumors and bad breath.
Summary:
Value types are already assumed to be stored by pointer (e.g.
`int val = *(node->data);`)
This commit just changes the current usage of the `ptr` modifier in the
ptr, not affecting the parser.
Reviewers: q66, segfaultxavi, bu5hm4n, felipealmeida
Reviewed By: q66
Subscribers: cedric, #reviewers, #committers, brunobelo
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10769
what is happening is that a file gets announced through eio_model
listing code, at this point of time, the monitor does not yet know about
the file. If the file now gets deleted between the annoncing and the
learning of the file from the monitor, then the file got an ADD event,
but no DEL event. Which is a bug.
With this commit there is a new API which asks the monitor if the file
already has the knowledge about the files existance, or not. A few
monitors like win32 inotify or cocoa do not have context about the file
directly, if the OS is now having the same bug, then we are again in
trouble, however, we canot do anything about that. In the case of kevent
or poll, this asks the context of the monitor if the file is already
there.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D10006
Summary:
this logic brings a few problems:
- When files are annonced here, without the monitor having the context
of the files, immidiat actions like deletion of the file are resulting
in no deletion event. Which is definitly a bug, so we need to wait here
for the monitor.
- When a new count is annonced before the files are there from the
monitor, we are heading towards the same issue - additionally, we might
already have files available, due to the custom counting that are not
annoncned through the monitor, which means, at a later pointer we are
annoncing a new file which is already available via the API.
Right now i do not see a way to continue with this code, it caused major
issues with our CI and the POLL backend, for now things do work again.
Depends on D9624
Reviewers: zmike, stefan_schmidt, cedric, felipealmeida
Reviewed By: zmike
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9625
i saw a segv in e/efm .. an eio call was called after it had been
canceled. this should never happen. ever. so ensure it does not once
an eio file has been canceled.
@fix
Summary:
when a monitor is destroyed, it unconditionally and immediately deletes
the monitor struct. this means that as soon as the monitor is dead, the
backend must never access the parent pointer again if its lifetime exceeds
the lifetime of the monitor (such as in threads)
the only member of the monitor data used by the fallback monitor is the
monitor path, so we can just copy it to the fallback data to avoid ever
needing to dereference this pointer
fixes reliability issues with efl sentry unit tests
@fix
Depends on D9708
Reviewers: cedric
Reviewed By: cedric
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9709
Summary:
if an event is emitted for a child that is added to the model during a
call to _efl_io_model_children_list(), it's possible that this child
will never be detected by the model's monitor/sentry if it is deleted
before the monitor can detect it, which means there will never be a
corresponding eio event emitted
in this case, ensure that we manually remove this child from the model
since we know we've just deleted it
this fixes reliability issues with efl io model monitor unit test
@fix
Reviewers: cedric
Reviewed By: cedric
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9708
Summary:
integrate mman.h to make Evil private to the EFL, as mman.h does not exist on Windows. After a discussion with raster, i include sys/mman.h only on non Windows platform.
One issue, though, is that src/modules/emotion/generic/Emotion_Generic_Plugin.h has inlined functions using mmap()
Test Plan: compilation on Windows
Reviewers: cedric, raster, zmike
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9542
do it once and remember the result from the first one. drops overhead
for sure by a chunk i actually could see in perf reports like about 1-2%
of cpu...
It kind of worked by luck for 6 months, but really shouldn't. This
is now a custom iterator that will walk the string part of the properties
only. It could become a generic iterator if necessary one day, but
for now, it is fine just here.
T7771
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9075
Summary:
if the wref automatically removes this pointer then there's no need to
remove the wref on the pointer
@fix
Depends on D8973
Reviewers: cedric
Reviewed By: cedric
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8974
Summary:
we need to to this here, otherwise we effectfily start the monitor
later, which means, we can miss a change in the filesystem. However,
this makes things a lot slower.
Reviewers: cedric
Reviewed By: cedric
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8526
Summary:
Little introduction into what eio did before this commit:
Efl.Io.Model creation:
- direct ls of a directory in a thread (A)
- take all the contents of a directory and feed it slowly back into
the mainloop
- when all events have been feeded back to the mainloop and have been
processed: start monitoring (B)
However, any file created between (A) and (B) will not be in the model,
since not the listing nor the monitoring did caputure it. Hence we need
to start monitoring before we actaully start listing. In the callbacks
we then check if we already published something.
ref T7311
Reviewers: zmike, cedric
Reviewed By: cedric
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7311
Differential Revision: https://phab.enlightenment.org/D8525
Ecore_Thread excpect resolution of the error and done case to be instantaneous,
while Eina_Future default scheduler linked with Ecore main loop is build around
asynchronous answer. This create a lot of potential. A better patch would be
to provide an Ecore_Thread helper that does the integration properly. Sadly
we are in release now, so this is basically what an helper would do, but
contained inside Efl_Io_Manager.
This also solve the same problem as D7970 and D8053, but it should avoid its
side effect.
Reviewed-by: YeongJong Lee <yj34.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D8371
There is no point in keeping a pointer to the main loop now that we
are using efl_future_then. This resolve potential bug with leftover
dangling weak reference as efl_future_then do require a free case
otherwise.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D8374
q66
Vincent Torri
Alastair Poole
Marcel Hollerbach
Felipe Magno de Almeida
Myoungwoon Roy, Kim
Elyes HAOUAS
Carsten Haitzler
Xavi Artigas
Lauro Moura
Mike Blumenkrantz
Daniel Kolesa
Cedric BAIL