ev_is_active - at which point?
common at gmx.ch
common at gmx.ch
Wed May 26 00:01:28 CEST 2010
Hi,
I got the following problem with ev_is_active():
I got a ev_timer, and it gets started, then something which takes a lot
of time happens, and I'd stop the timer if ev_is_active claims the timer
is still active.
But, ev_is_active reports the timer is not active, I do not disable the
timer, and the timers callback gets fired afterwards.
Thats the problem.
ev_is_active reports the timer is inactive, and the callback gets fired.
Sounds scary, yes.
I used gdb to verify:
ev_is_active is false:
(gdb) p con->events.dns_timeout
$6 = {active = 0, pending = 1, priority = 0, data = 0x9a2b8c8, cb =
0x805a410 <the_cb>,
at = -3.4154873266816139, repeat = 0}
but later on, the callback fires:
(gdb) p con->events.dns_timeout
$7 = {active = 0, pending = 0, priority = 0, data = 0x9a2b8c8, cb =
0x805a410 <the_cb>,
at = -3.4154873266816139, repeat = 0}
I noticed the 'pending' field, so when is a not repeating ev_timer inactive?
If I ask to disable an ev_timer in the same ev_loop iteration which
would fire the callback (ev_timer.pending = 1), is the
ev_is_active(ev_timer) meant to be true or false?
I'd expect it to be true - as I did not call ev_timer_stop on it yet,
and the callback did not come in yet, but I think I'm wrong.
Attached is a sample program, t1_cb is expected to stop t2, so t2_cb
never gets called, but t2_cb is called always.
./timertest
called t1_cb loop 0x7fd720899200 w 0x601100 revents 256
called t2_cb loop 0x7fd720899200 w 0x601080 revents 256
Thanks,
Markus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: timertest.c
Type: text/x-csrc
Size: 922 bytes
Desc: not available
URL: <http://lists.schmorp.de/pipermail/libev/attachments/20100526/d3b66bd4/attachment.c>
More information about the libev
mailing list