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>
if try_no_queue is used - its a thread that clearly wantt to be out of
the queue to run on its own so probably wants to wake up accurately
and thus not be a backgroun rpriority task but and urgent one. ensure
we set up priority accordingly as we didn't before. this should fix
scheduling when under load for vsync
@fix
see the _eina_thread_internal() function
r = c->func((void*) c->data, eina_thread_self());
The second param has been missed in ecore_thread_worker, ecore_direct_worker functions.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D10073
this avoids the case where the main loop is waiting on a thread
and that same thread is waiting on the main loop
@fix
Differential Revision: https://phab.enlightenment.org/D6438
if a thread is actively waiting on the main loop in order to proceed
with its exit, a flush here avoids the case where the thread waits
until the main loop has exited
Differential Revision: https://phab.enlightenment.org/D6437
since this is now a smaller wait interval, looping more times helps
ensure success for threads which have longer blocking operations
between lifetime checks
Differential Revision: https://phab.enlightenment.org/D6436
Summary:
now that ecore accurately waits on all threads while exiting, this
loop needs to run much more frequently in order to avoid waiting for
an unreasonably long time when exiting
Reviewers: ManMower, devilhorns
Reviewed By: ManMower
Subscribers: cedric, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6427
these threads are still managed by the main loop, meaning they must be
accounted for so that they can be waited on if necessary during shutdown
this resolves some issues where ecore-con threads would persist after the
main thread had exited or called ecore_shutdown
@fix
fix T7041
this is the final version of the patch and not the mangled version which
was previously committed
Differential Revision: https://phab.enlightenment.org/D6354
these threads are still managed by the main loop, meaning they must be
accounted for so that they can be waited on if necessary during shutdown
this resolves some issues where ecore-con threads would persist after the
main thread had exited or called ecore_shutdown
@fix
fix T7041
Differential Revision: https://phab.enlightenment.org/D6354
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.
Waiting would sometimes return as if the thread finished correctly while it is still running.
This is because we’re waiting for the waiter data to be null… but this is always the case if the user-passed data is null!
@fix
it can contain old callback values which are not overwritten in every
case. This just ensures that in both cases, empty trasher or none empty
trasher, are returning the same state of the struct.
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 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.
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).
Felipe Magno de Almeida
Carsten Haitzler
Woochanlee
Vincent Torri
Mike Blumenkrantz
Cedric BAIL
Mike Blumenkrantz
Umesh Tanwar
Marcel Hollerbach
Chidambar Zinnoury
Guilherme Iscaro
Gustavo Sverzut Barbieri
Shinwoo Kim
Jérémy Zurcher
Cedric Bail
Mariusz Grzegorczyk
Chris Michael
Cedric Bail
Lucas De Marchi
Gustavo Sverzut Barbieri