NOTE: if you build ecore without pthread support, you really should know
that it is a bad idea. Only people without pthread support on their
device/C library should disable it.
SVN revision: 50200
A buggy standard.h caused some parser errors in the previous committed
patch generated by Coccinelle. This commit find the other places.
SVN revision: 50052
list of values. Recent versions dropped it and return
arrays instead. Adapt code to use arrays unconditionally
(arrays were present in earlier libxcb versions).
Patch by Mikhail Gusarov
SVN revision: 49667
when IPv4 and IPv6 exist, if you ask AF_INET6, it will first
try IPv6 before falling back to IPv4 address.
So now ecore_con_ares will prefer IPv6 if available.
SVN revision: 49552
* process filters in their own function
* remove commented printf
* remove trailing white space
* lower indentation needed by breaking loop instead of a big if
SVN revision: 49436
When walking the filters' list, using event_current might screw a
recursive main loop that had to process filters *and* events on the
first iteration. Thus, use a new pointer to mark the current event being
treated when walking filters' list.
Tests for this one is difficult. I'll try to think about a test later.
SVN revision: 49435
* _ecore_event_purge_deleted() purges only events marked with
delete_me
* _ecore_events_exist() walks the events list to control that
at least one event with delete_me == 0 exists
Tests coming in a separate patch.
SVN revision: 49434
This fixes the following scenario:
1) An event handler starts another main loop
2) The new main loop processes all the remaining event_handlers of this
event and the remaining events
3) New events are added to the events list
4) A new iteration occurs
Prior behavior was that on (4) the events already processed were
triggered again. The code added to ecore_suite shows a test case,
similar to the one that is fixed now for modal dialogs on WebKit-EFL. I
preferred to let the INF() messages in order to be easy to copy, paste
and debug outside of the suite if anyone wants to. When the number of
tests grows more, we might want to separate them in different files.
By: Lucas De Marchi <lucas.demarchi@profusion.mobi>
SVN revision: 49390
Timers' list is and *ordered list*. Therefore, timers can be added
before timer_current in an inner mainloop. Reschedule timer_current in
this case before looping through timers' list.
Thanks to Barbieri for the insight.
The following test didn't work before and it's ok now (I'm adding it to
ecore_suite too).
static int _timer3(void *data)
{
printf("timer 3, do nothing\n");
return 0;
}
static int _timer2(void *data)
{
printf("timer 2, quit inner\n");
ecore_main_loop_quit();
return 0;
}
static int _timer1(void *data)
{
int *times = data;
(*times)++;
printf("BEGIN: inner\n");
ecore_timer_add(0.3, _timer2, NULL);
ecore_timer_add(0.1, _timer3, NULL);
ecore_main_loop_begin();
printf("END: inner\n");
ecore_main_loop_quit();
return 0;
}
int main(void)
{
int times = 0;
ecore_init();
ecore_timer_add(1.0, _timer1, ×);
printf("BEGIN: main\n");
ecore_main_loop_begin();
assert(times == 1);
printf("timer1 called %d times \n", times);
printf("END: main\n");
return 0;
}
By: Lucas De Marchi <lucas.demarchi@profusion.mobi>
SVN revision: 49245
rendering. to turn on:
1.
configure with --enable-async-render
2.
export EVAS_RENDER_MODE=non-blocking
presto. necessitates some api swizzling (thus the expedite. ecore etc. changes)
the kind of results you get on a desktop:
http://www.rasterman.com/files/evas-async-vs-none.html
SVN revision: 49087
"cd ecore && ./autogen.sh --enable-tests &&make && make check-local" was
failing.
Make sure to build ecore_suite before trying to run it.
SVN revision: 49053
I’ve prepared basic patch to add support for custom malloc/free functions for
buffer management. (with changes to api from raster to addd void *data param
to alloc/free callbacks and naming and ordering changes).
SVN revision: 49044
* On Windows, the values returned by pipe() are sockets.
Hence they can be huge. Iterate over the list of "fds"
instead of the max value
* In the loop which iterates over the win32 handlers,
we never go to the next element, so infinite loop...
SVN revision: 48807
Quartz is the name of the graphic library
Cocoa is the Objective C API to build applications
I can't test this so maybe I have forgotten some
modifications to do. Please report any problem in
that thread
SVN revision: 47339
If an fd_handler created a recursive main loop (just called
ecore_main_loop_begin()), then this recursive main loop should
continue to process fd_handlers from there and on, thus
fd_handler_current (and win32_handler_current) was added. When going
back from recursion, the current iterator should be updated properly.
This patch also fixes the deletion of fd_handler from recursive main
loops by reference counting them. This way, the node will not be
free()d inside inner loop cleanups and then crash when going back to
outer loop.
PS: win32 code is untested (or even compiled).
The following test case used to crash but not anymore:
#include <Ecore.h>
#include <Eina.h>
#include <unistd.h>
static int _log_dom;
#define INF(...) EINA_LOG_DOM_INFO(_log_dom, __VA_ARGS__)
#define ERR(...) EINA_LOG_DOM_ERR(_log_dom, __VA_ARGS__)
static Ecore_Fd_Handler *handle;
static int a[2], b[2];
static int cb2(void *data, Ecore_Fd_Handler *h)
{
INF("cb2 - delete cb1 handle");
ecore_main_fd_handler_del(handle);
ecore_main_loop_quit(); /* quits inner main loop */
return 0;
}
static int cb1(void *data, Ecore_Fd_Handler *h)
{
unsigned char ch = 222;
INF("cb1: begin");
INF(" add cb2");
ecore_main_fd_handler_add(b[0], ECORE_FD_READ, cb2, NULL, NULL, NULL);
INF(" wake up pipe b");
if (write(b[1], &ch, 1) != 1)
ERR("could not write to pipe b");
INF(" inner main loop begin (recurse)");
ecore_main_loop_begin(); /* will it crash due
* ecore_main_fd_handler_del(handle)
* inside cb2()? It used to!
*/
INF("cb1: end");
ecore_main_loop_quit(); /* quits outer main loop */
return 0;
}
int main(void)
{
unsigned char ch = 111;
ecore_init();
_log_dom = eina_log_domain_register("test", EINA_COLOR_CYAN);
pipe(a);
pipe(b);
/*
* Creating a new main loop from inside an fd_handler callback,
* and inside this new (inner) main loop deleting the caller
* callback used to crash since the handle would be effectively
* free()d, but when the recursion is over the pointer would be
* used.
*/
INF("main: begin");
handle = ecore_main_fd_handler_add
(a[0], ECORE_FD_READ, cb1, NULL, NULL, NULL);
INF("main: wake up pipe a");
if (write(a[1], &ch, 1) != 1)
ERR("could not write to pipe a");
ecore_main_loop_begin();
INF("main: end");
return 0;
}
SVN revision: 46443
If an event handler/filter created a recursive main loop (just called
ecore_main_loop_begin()), then this recursive main loop should
continue to process events/handlers/filters from there and on, thus
event_current/event_filter_current/event_handler_current were
added. When going back from recursion, the current iterator should be
updated properly.
The following test case used to crash but not anymore:
#include <Ecore.h>
#include <Eina.h>
static int _log_dom;
#define INF(...) EINA_LOG_DOM_INFO(_log_dom, __VA_ARGS__)
static Ecore_Event_Handler *handle;
static int cb2(void *data, int type, void *event)
{
INF("cb2 - delete cb1 handle");
ecore_event_handler_del(handle);
ecore_main_loop_quit(); /* quits inner main loop */
return 0;
}
static int cb1(void *data, int type, void *event)
{
Ecore_Event *e;
INF("cb1: begin");
INF(" add cb2");
type = ecore_event_type_new();
ecore_event_handler_add(type, cb2, NULL);
e = ecore_event_add(type, NULL, NULL, NULL);
INF(" add event to trigger cb2: event=%p", e);
INF(" inner main loop begin (recurse)");
ecore_main_loop_begin(); /* will it crash due
* ecore_event_handler_del(handle) inside
* cb2()? It used to!
*/
INF("cb1: end");
ecore_main_loop_quit(); /* quits outer main loop */
return 0;
}
int main(void)
{
Ecore_Event *e;
int type;
ecore_init();
_log_dom = eina_log_domain_register("test", EINA_COLOR_CYAN);
/*
* Creating a new main loop from inside an event callback, and inside
* this new (inner) main loop deleting the caller callback used to
* crash since the handle would be effectively free()d, but when the
* recursion is over the pointer would be used.
*/
type = ecore_event_type_new();
INF("main: begin");
handle = ecore_event_handler_add(type, cb1, NULL);
e = ecore_event_add(type, NULL, NULL, NULL);
INF(" add event to trigger cb1: event=%p", e);
INF(" main loop begin");
ecore_main_loop_begin();
INF("main: end");
return 0;
}
SVN revision: 46419
Add reference counting to events, event filters and event handlers so
they can recurse main loops.
Note that the required "continuation" when entering main loops is not
there, thus recursion will restart and this will fail badly in lots of
cases. This should be fixed in future commits.
SVN revision: 46417
recursive main loops.
Unlike idlers, timers seems to work reasonably well with main loops, I
*think* they might fail since it used a boolean to flag running as
opposed to a reference count with incremental increments/decrements. I
could not write a test case to demonstrate so.
The now code should be simpler, particularly the
_ecore_timer_call(). It will also consider the previous position when
entering recursive main loops, preserving the order.
Deletion of timers are delegated to ecore_main.c, that was already
calling _ecore_timer_cleanup() after timers were executed.
SVN revision: 46416
If an idle_exiter created a recursive main loop (just called
ecore_main_loop_begin()), then this recursive main loop should
continue to process idle_exiters from there and on, thus
idle_exiter_current was added. When going back from recursion, the
current iterator should be updated properly.
This patch also fixes the deletion of idle_exiters from recursive
main loops by reference counting them. This way, the node will not be
free()d inside inner loop cleanups and then crash when going back to
outer loop.
The following test case used to crash but not anymore:
#include <Ecore.h>
#include <Eina.h>
static int _log_dom;
#define INF(...) EINA_LOG_DOM_INFO(_log_dom, __VA_ARGS__)
static Ecore_Idle_Exiter *handle;
static int idler(void *data)
{
INF("idler");
return 1;
}
static int timer(void *data)
{
INF("timer (exited idle!)");
return 0;
}
static int exit_idle(void *data)
{
INF("add request (timer) to exit idle");
ecore_timer_add(0.0, timer, NULL);
return 0;
}
static int cb2(void *data)
{
INF("cb2 - delete cb1 handle");
ecore_idle_exiter_del(handle);
ecore_main_loop_quit(); /* quits inner main loop */
return 0;
}
static int cb1(void *data)
{
INF("cb1: begin");
INF(" add cb2");
ecore_idle_exiter_add(cb2, NULL);
INF(" add exit idler");
ecore_idler_add(exit_idle, NULL);
INF(" inner main loop begin (recurse)");
ecore_main_loop_begin(); /* will it crash due ecore_idle_exiter_del(handle)
* inside cb2()? It used to!
*/
INF("cb1: end");
ecore_main_loop_quit(); /* quits outer main loop */
return 0;
}
int main(void)
{
ecore_init();
_log_dom = eina_log_domain_register("test", EINA_COLOR_CYAN);
/*
* Creating a new main loop from inside an idle_exiter callback,
* and inside this new (inner) main loop deleting the caller
* callback used to crash since the handle would be effectively
* free()d, but when the recursion is over the pointer would be
* used.
*/
INF("main: begin");
handle = ecore_idle_exiter_add(cb1, NULL);
ecore_idler_add(idler, NULL);
ecore_idler_add(exit_idle, NULL);
ecore_main_loop_begin();
INF("main: end");
return 0;
}
SVN revision: 46410
If an idle_enterer created a recursive main loop (just called
ecore_main_loop_begin()), then this recursive main loop should
continue to process idle_enterers from there and on, thus
idle_enterer_current was added. When going back from recursion, the
current iterator should be updated properly.
This patch also fixes the deletion of idle_enterers from recursive
main loops by reference counting them. This way, the node will not be
free()d inside inner loop cleanups and then crash when going back to
outer loop.
The following test case used to crash but not anymore:
#include <Ecore.h>
#include <Eina.h>
static int _log_dom;
#define INF(...) EINA_LOG_DOM_INFO(_log_dom, __VA_ARGS__)
static Ecore_Idle_Enterer *handle;
static int idler(void *data)
{
INF("idler");
return 1;
}
static int cb2(void *data)
{
INF("cb2 - delete cb1 handle");
ecore_idle_enterer_del(handle);
ecore_main_loop_quit(); /* quits inner main loop */
return 0;
}
static int cb1(void *data)
{
INF("cb1: begin");
INF(" add cb2");
ecore_idle_enterer_add(cb2, NULL);
INF(" inner main loop begin (recurse)");
ecore_main_loop_begin(); /* will it crash due ecore_idle_enterer_del(handle)
* inside cb2()? It used to!
*/
INF("cb1: end");
ecore_main_loop_quit(); /* quits outer main loop */
return 0;
}
int main(void)
{
ecore_init();
_log_dom = eina_log_domain_register("test", EINA_COLOR_CYAN);
/*
* Creating a new main loop from inside an idle_enterer callback,
* and inside this new (inner) main loop deleting the caller
* callback used to crash since the handle would be effectively
* free()d, but when the recursion is over the pointer would be
* used.
*/
INF("main: begin");
handle = ecore_idle_enterer_add(cb1, NULL);
ecore_idler_add(idler, NULL);
ecore_main_loop_begin();
INF("main: end");
return 0;
}
SVN revision: 46408
If an idler created a recursive main loop (just called
ecore_main_loop_begin()), then this recursive main loop should
continue to process idlers from there and on, thus idler_current was
added. When going back from recursion, the current iterator should be
updated properly.
This patch also fixes the deletion of idlers from recursive main loops
by reference counting them. This way, the node will not be free()d
inside inner loop cleanups and then crash when going back to outer
loop.
The following test case used to crash but not anymore:
#include <Ecore.h>
#include <Eina.h>
static int _log_dom;
#define INF(...) EINA_LOG_DOM_INFO(_log_dom, __VA_ARGS__)
static Ecore_Idler *handle;
static int idler(void *data)
{
INF("idler");
return 1;
}
static int cb2(void *data)
{
INF("cb2 - delete cb1 handle");
ecore_idler_del(handle);
ecore_main_loop_quit(); /* quits inner main loop */
return 0;
}
static int cb1(void *data)
{
INF("cb1: begin");
INF(" add cb2");
ecore_idler_add(cb2, NULL);
INF(" inner main loop begin (recurse)");
ecore_main_loop_begin(); /* will it crash due ecore_idler_del(handle)
* inside cb2()? It used to!
*/
INF("cb1: end");
ecore_main_loop_quit(); /* quits outer main loop */
return 0;
}
int main(void)
{
ecore_init();
_log_dom = eina_log_domain_register("test", EINA_COLOR_CYAN);
/*
* Creating a new main loop from inside an idler callback, and inside
* this new (inner) main loop deleting the caller callback used to
* crash since the handle would be effectively free()d, but when the
* recursion is over the pointer would be used.
*/
INF("main: begin");
handle = ecore_idler_add(cb1, NULL);
ecore_idler_add(idler, NULL);
ecore_main_loop_begin();
INF("main: end");
return 0;
}
SVN revision: 46406
We should start doing unit-test for ecore, accumulating these
problems. Follows the test case:
#include <Ecore.h>
#include <Eina.h>
static int _log_dom;
#define INF(...) EINA_LOG_DOM_INFO(_log_dom, __VA_ARGS__)
static int quiter(void *data)
{
INF("quit!");
ecore_main_loop_quit();
return 1;
}
static int idler(void *data)
{
INF("idler");
return 1;
}
static int cb1(void *data)
{
INF("cb1");
ecore_timer_add(0.0, quiter, NULL);
return 0;
}
int main(void)
{
ecore_init();
_log_dom = eina_log_domain_register("test", EINA_COLOR_CYAN);
/*
* Create a main loop with just idlers, there is a special case
* for just idlers without timers in ecore.
*
* From idler, add a timer that quits the application. It should
* always quit.
*
* If it does not quit, then there is a bug of new timers not
* being immediately detected and system never exits idle.
*/
INF("main: begin");
ecore_idler_add(cb1, NULL);
ecore_idler_add(idler, NULL);
ecore_main_loop_begin();
INF("main: end");
return 0;
}
SVN revision: 46405
if using ecore_main_loop_begin() multiple times (reentrant/recursive)
with glib doing threads, then it would deadlock since the same thread
would get the lock it already have.
multiple ecore_main_loop_begin() is required to implement WebKit's
alert/confirm/prompt dialogs since there is no async reply with
callbacks, rather one must return the value.
By: Lucas de Marchi
SVN revision: 46361