in reply to AnyEvent timers by EV

My sense is that you are comparing apples and oranges here:   a local timer-watcher, which by definition concerns only a single machine (yours), is being weighed against the timeouts of a transaction that is being attempted against a remote.   (There seems to be some specific discussion of this issue in the “Timing Issues” section of the page for AnyEvent.)   I suspect that the “every odd call” phenomenon that you seem to be observing is, in fact, just a fluke.   What you are probably dealing with here is an innocuous expression of what’s called a “race condition.”   The particular results that you deem to be meaningful are probably just the luck of the draw.

Replies are listed 'Best First'.
Re^2: AnyEvent timers by EV
by Anonymous Monk on Apr 01, 2015 at 22:22 UTC

    What you are probably dealing with here is an innocuous expression of what’s called a “race condition.”

    Balooney, its simple granularity, same as with sleep

      Not so fast . . . kindly please do not automatically presume that I know not whereof I speak, and thus to dismiss what <<I>&;gt; say on just that reason.   :-)

      In the instant case, a local timer, running for so-many milliseconds locally, is being set against a timeout of a remote TCP/IP exchange.   Necessarily, a timeout against a remote machine will require some additional milliseconds to resolve ... milliseconds spent informing the client that a timeout has, in fact, occurred.   The AnyEvent authors were obviously very sensitive to such issues, and they actually spent quite a bit of time in their documentation discussing it.   It appears to me that the OP’s test-case does not take these issues into proper account, thereby leading to the (erroneous?) observation of “even/odd.”

      Basically, “it will take you somewhat-more than 200 milliseconds to conclude that a 200-millisecond timeout has timed-out.”   (And, as Anonymous Monk originally observed, it is actually quite unpredictable just how many “more than” milliseconds, might be required.)   A strictly-local timer knows nothing of real-world network delays, whereas a valid conclusion cannot ignore them.   C’est la guerre ...

      EDIT:   Kindly now draw your attention to what krambambuli subsequently posted.   I think he hit an important nail on the head here ... and something I did not know ... to decisively explain the “even/odd” behavior.

        I have made new test-code for check pure Timers. And they behave like I expect and everything is clear for me...
        So It's seems that problem from my 1 test-code is related to network "magic".

        test-code 2: pure timers
        #!/usr/bin/perl use common::sense; use AnyEvent; use Data::Dumper; sub do { my $iter = shift; my $cv = AnyEvent->condvar; my ($n, $t, $d, $e); ($n, $t) = (AnyEvent->now, AnyEvent->time); $d = $t-$n; say "$iter start timer diff = $d, time = $t, now = $n"; my $timer = AnyEvent->timer( after => 2, cb => sub { warn "Timer\n"; $cv->send }, ); $cv->recv; ($n, $t, $e) = (AnyEvent->now, AnyEvent->time, AnyEvent->time - $ +t); $d = $t-$n; say "$iter got timer diff = $d, elapsed = $e, time = $t, now = $n" +; } for (1..4) { &do($_); sleep(5); warn "\n"; }
        And result:
        1 start timer diff = 0.000634908676147461, time = 1427985442.36442, no +w = 1427985442.36378 Timer 1 got timer diff = 7.31945037841797e-05, elapsed = 2.00119400024414, t +ime = 1427985444.36561, now = 1427985444.36554 2 start timer diff = 5.00071620941162, time = 1427985449.36625, now = +1427985444.36554 Timer 2 got timer diff = 0.000667810440063477, elapsed = 0.00254702568054199 +, time = 1427985449.3688, now = 1427985449.36813 3 start timer diff = 5.00153064727783, time = 1427985454.36966, now = +1427985449.36813 Timer 3 got timer diff = 4.67300415039062e-05, elapsed = 0.00129199028015137 +, time = 1427985454.37095, now = 1427985454.3709 4 start timer diff = 5.00066781044006, time = 1427985459.37157, now = +1427985454.3709 Timer 4 got timer diff = 0.000627279281616211, elapsed = 0.00244379043579102 +, time = 1427985459.37401, now = 1427985459.37338
        1 - timer invoked exactly after 2 sec of real time
        2 - timer set when internal time and real time has 5 sec lag. So timer invoked immediately.
        3..4 like 2 iteration

        But Im still interested in my first test-code... just for self-education.

        Not so fast . . . kindly please do not automatically presume that I know not whereof I speak, and thus to dismiss what say on just that reason. :-)

        Automatically? I quoted the baloney line .. timing issues (fuzziness) do not mean race condition they mean timing issues ... doesn't matter at what rate you blink if you've got baloney glasses