Patch 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
EAPI is the only solution that worked for MSVC.
Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com>
Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev>
Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
Summary:
As delete_me flag was not updated in the delete callback it dosen't
call ecore_ipc_client_del() on the client hence the leak.
Reviewers: Hermet, raster, bu5hm4n, CHAN
Reviewed By: Hermet, CHAN
Subscribers: CHAN, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11927
Summary: This fixes especially the execution of edje_cc on Windows
Test Plan: execution of edje_cc
Reviewers: cedric, raster
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7834
conversion to efl.nmet didnt deal with null/0 zised payloads properly
and tried to send them, resulting in lots of ERR complaints which were
not errors. fix that to not try and send such empty payloads
@fix
it wasn't looking at the copier queue "todo" at all thus skipping it
on flush. this will fix flushing of ecore ipc message buffers. this
happens to also now fix terminology's "one process" mode.
@fix
This reverts commit 135154303b.
Revert "efl: move signal events from efl.loop to efl.app"
This reverts commit 3dbca39f98.
Revert "efl: add test suite for efl_app"
This reverts commit 3e94be5d73.
Revert "efl: create Efl.App class, the parent of Efl.Loop"
This reverts commit 28fe00b94e.
Go back to before efl.app because I think this should be done with
superclassing here not a parent object. reasons?
1. multiple loops per single thread make no sense. so if multilpe loop
objects they wont be contained in a single app object and then deleted
like this.
2. the app object is not really sharable in this design so it cant be
accessed from other threads
3. it makes it harder to get the main loop or app object (well 2 func
calls one calling the other and more typing. it is longer to type and
more work where it is not necessary, and again it can't work from
other threads unless we go duplicating efl.app per thread and then
what is the point of splittyign out the signal events from efl.loop
then?)
etc.
by deleting the socket they wont mutually exclude at bind which means
eny new server just nides the pror one and you can get lots of copies
of the same server. this wasnt the case before. it shouldnt have been.
i think ther was an rm path for stale sockets when connecting failed
or something. anyway... this here was causing multilpe efreetd's and
all sorts of nastiness. this is the root cause. so... fix it.
@fix
An old comment mentioned that this was explicitely not unregistered, but
I believe the comment isn't valid since ecore_event_type_flush() was
introduced.
This patch sets some Ecore_Con flags that were missing after
the EO migration. These flags must be set in order
maintain the Ecore_IPC behaviour before Ecore_Con EO was implemented.
Fixes T5722
Some applications will create the handle, immediately send data, flush
and delete it, expecting the data to be sent to remote peer.
This is a bad behavior as the application would become unresponsive
until the connection is established, data can be written (since
depends on server consuming it), then allow it to be closed.
A proper behavior here would be to chain based on events, with the
usage of a copier would be simply wait for "done" event.
However the legacy API allowed this and terminology depends on this
awkward "feature", thus be bug-compatible.
This fixes T5015.
In the old/legacy API the socket would be opened early in non-blocking
mode (connect returned errno==EINPROGRESS), with UNIX socket being
path-validated early and returning NULL as 'server' handle.
Some applications relied on this instead of monitoring the "ERROR"
events, considering the connection to be successful if there was a
handle -- this was the case with Terminology after it moved from DBus
to Ecore_Ipc.
Although this is not correct, we must keep compatibility and thus we
stat() in compatibility layer, failing early as the old API would do.
These legacy API had the nasty behavior of keeping handles alive until
the pending events were dispatched, this could happen after the module
itself was shutdown, resulting in log to unregistered domains.
Then do not unregister the domain -- eina_shutdown will avoid leaks
anyway.
I always got this during the build:
lib/ecore_ipc/ecore_ipc.c:537:6: warning: ‘old_mask’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
Looking at the code it really is a false positive. Gettign the mask is behind
an if it is the same if condistion used before writing it. Anyway, silencing the
warning here.
The may_block parameter is useful to force a flush without blocking on
read/write, sometimes particularly useful if ignore_line_delimiter is
true, then you get the data events without blocking -- as if a server
sending some content misses a trailing line delimiter, you do not want
to block on recv() but still want to flush data to user.
The ignore_line_delimiter parameter is useful if we're going to close
the copier and want to flush pending data which may exist due missing
trailing terminator. The close method will also force that if
destination can take more data.
Each client (Ecore_Ipc_Client) is very similar to the handle
configured by ecore_ipc_server_connect() (the dialer), except we do
not have events such as "connected" and "error", as well as we don't
delete the socket as it's owned by the server, instead we close it.
The UNIX socket is configured similarly to ecore_con, setting the same
masks and mode for directories.
Use the new Efl.Net.Dialer classes to implement
ecore_con_server_connect() scenario.
Note that since Windows still doesn't provide any equivalent to
Efl.Net.Dialer.Unix, we keep the legacy code for it.
Using the ecore_ipc_server_example with -m/--single-message, if we
deleted the client from the callback it would find a dead "cl".
As the "cl" handle is removed from svr->clients before it's deleted,
it's safe to check if we have that handle in the list before
proceeding.
The flag 'delete_me' is set when there are pending events to be
dispatched. Once these events are freed, they will check if the server
was pending delete and call ecore_ipc_server_del() again, thus we must
not return, otherwise data will be leaked.
Summary: During mobile product testing, we got a crash with callstack which suggest server is getting deleted prior to client. On valgrind analysis we found invalid write operation with same callstack. callstack is pasted in comment section.
Test Plan: create a situation where server got deleted prior to client.
Reviewers: raster, cedric
Subscribers: govi, rajeshps, jpeg
Differential Revision: https://phab.enlightenment.org/D4152
Summary:
buf is always NULL (already freed and set to NULL).
We don't need to add NULL checking and free it.
Reviewers: raster, cedric, Hermet
Subscribers: seoz, cedric
Differential Revision: https://phab.enlightenment.org/D2783
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary: The allocated memory is not released before return.
Lost track of the CID.
Test Plan: Run static analysis tool such as prevent
Reviewers: raster, cedric
Reviewed By: cedric
Subscribers: cedric, seoz
Differential Revision: https://phab.enlightenment.org/D1746
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
According to clang static analyzer it is possible to find a path where
buf and svr->buf are pointing to the same array, better be safe than sorry.
Arguably this code could be more readable if it was using Eina_Binbuf.
Felipe Magno de Almeida
Yeongjong Lee
Elyes HAOUAS
Subhransu Mohanty
Hosang Kim
Mike Blumenkrantz
Vincent Torri
Cedric BAIL
Carsten Haitzler
Mike Blumenkrantz
Jean-Philippe Andre
Guilherme Iscaro
Gustavo Sverzut Barbieri
Stefan Schmidt
Jee-Yong Um
Prince Kumar Dubey
Amitesh Singh
Thiep Ha
Shinwoo Kim
Cedric Bail