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
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
* add 2 internal ecore_exe functions as ecore_signak.c uses Ecore_Exe members
no test is done in those 2 functions
* remove standard headers from ecore_private.h
SVN revision: 44862
* if ecore_events are in the queue, timeout 0 is passed and
MsgWaitForMultipleObjects returns immediately, which can
lead to problems. If timeout is 0, we do nothing (that is,
we wait for the ecore_events to finish first)
* manage the case when MsgWaitForMultipleObjects returns WAIT_FAILED
SVN revision: 43547
To reach this case, have a timer that would not be fired on
_ecore_main_loop_iterate_internal(), for example it's not ready yet
(just_added==1), system would get into this inner loop and would never
stop, since there is timer expired now (next_time == 0.0), if we go to
start_loop it would just get into the same loop, not dispatching and
timers.
Python test 04-idler.py triggered that problem.
SVN revision: 41342
sent by ecore_pipe. The programs based on Ecore on Windows
do not take 100% of the cpu power anymore.
Patch by Lars Munch, modified by me (formatting + guards)
SVN revision: 41179
If there are no other main loop activity than a idlers and one idler
adds a timer, the new (and unique) timer would be ignored since it's
flagged as "just_added" and thus next iteration will not consider it,
possible entering an infinite wait as it could be the only thing to do
in main loop.
Antognolli found this nasty bug while handling timeout-and-die in
Ethumb, where the "disconnect" event is dispatched by EDBus from idler
and it was adding a timer to shutdown the daemon after a while without
clients.
By: Rafael Antognolli <antognolli@profusion.mobi>
SVN revision: 40923
this fix a problem on Windows: the ecore main loop
hanged because of GetMessage() if next_time had a
random value.
patch by Lars Munch
SVN revision: 39178
* add vim header
* include config.h when necessary
* fix the order of some include
* move the standard header in ecore_private.h to the source files
I have recompiled all the efl and e17, and e17 seems to work fine with these changes.
If you encounter problems with that commit, let me know.
SVN revision: 38864
* both exe run functions now use the same code.
* don't allocate pipes that wan't be used. This made the code much cleaner.
* track and free the exe timers as needed.
E still reports a naughty null timer free at shutdown time, but I don't
think its in ecore_exe. I'll valgrind it later.
The error fd handler is curently an identical copy of the read fd handler,
with only the names changed. That's a big slab of code that is duplicated.
I'll merge the two into something generic next.
raster also mentioned that say the first ten lines or so of stderr should
be thrown into a dialog and shown to the user. I don't know if there is a
way to do that from ecore, or if the user of ecore_exe has to do that
themselves. The stderr support does line buffered mode just like the read
support, but has not been tested yet. I'll test properly after the merge.
SVN revision: 19700
where (rougly) time is spent (as it runs - dynamically). quite useful if your
code is dropping frames to keep animation going - but u'd like to know when
exactly its happening so you can lean down the graphics design or the code in
those situations.
SVN revision: 9379
Carsten Haitzler
Vincent Torri
Gustavo Sverzut Barbieri
Sebastian Dransfeld
Cedric BAIL
Christopher Michael
Peter Wehrfritz
doursse
Mike Frysinger
David Walter Seikel
tsauerbeck
sebastid
ncn
xcomputerman