Then I would cancel the timer when starting the HTTP request, and relaunch the timer in the HTTP request on_body callback (and likely in the on_error callback too). You can "immediately" launch a timer by launching it with after => 0 - this will launch the timer callback the next time the event loop is entered.

Nice idea, that could actually work, I'll try that in a minute.

I was just hoping that there was some kind of $condvar->send/recv mechanism that supported lock()/unlock() so that I could write something like

       
$condvar->lock();
http_get "http://blah", sub { $condvar->unlock();
     print $_[1] };
[download]

sub timer_callback {
    $condvar->lock();
    # ...
    $condvar->unlock();
}
[download]

This cannot work - if you expect ->lock() to block until the semaphore is released, how can it continue to execute the remaining code elsewhere?

I would either use a plain boolean variable, like you did in your first case, and keep the timer running:

my $critical;
sub on_timer {
    if (! $critical) {
        ...
    };
};
[download]

... or manually restart the timer when it's allowed to restart again. The guard values returned from creating a timer allow you to conveniently stop a timer.