Re^4: AnyEvent: How to protect critical sections?

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]

Comment on Re^4: AnyEvent: How to protect critical sections? Select or Download Code

Replies are listed 'Best First'.
Re^5: AnyEvent: How to protect critical sections? by Corion (Patriarch) on May 17, 2011 at 21:03 UTC
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.	[reply] [d/l] [select]
Re^6: AnyEvent: How to protect critical sections? by saintmike (Vicar) on May 17, 2011 at 21:25 UTC
This cannot work - if you expect ->lock() to block until the semaphore is released, how can it continue to execute the remaining code elsewhere? The same way that $condvar->recv() blocks and lets code run elsewhere. Only problem: $condvar->recv() cannot be called from within a callback, according to the AnyEvent docs: "Note that doing a blocking wait in a callback is not supported by any event loop, that is, recursive invocation of a blocking "->recv" is not allowed,".	[reply]
Re^7: AnyEvent: How to protect critical sections? by Anonymous Monk on May 18, 2011 at 19:55 UTC
Indeed, if you would need to do that, you need to use real threads (e.g. Coro) - the limitation of condvars is partially lifted under Coro.	[reply]