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