| Subject: | run() can't be called inside AnyEvent callback subroutines |
Between AnyEvent-Process 0.01 and 0.02, the following code was added to run() just before it returns, presumably in response to a bug:
# We need this to allow AE collecting pending signals and prevent accumulation of zombies
$self->_yield;
where _yield() is defined as:
sub _yield {
my $cv_yield = AE::cv;
AE::postpone { $cv_yield->send };
$cv_yield->recv;
}
The use of a blocking condvar here means that run() can't be called from within an AnyEvent callback subroutine, at least not in the same way that it's used in t/AnyEvent-Process-Pipe-Handle.t, which really limits the module's usefulness (for me, at least). From the AnyEvent documentation:
"Note that condition variables recurse into the event loop - if you have two pieces of code that call ->recv in a round-robin fashion, you lose. Therefore, condition variables are good to export to your caller, but you should avoid making a blocking wait yourself, at least in callbacks, as this asks for trouble.
"Not all event models support a blocking wait - some die in that case (programs might want to do that to stay interactive), so if you are using this from a module, never require a blocking wait. Instead, let the caller decide whether the call will block or not (for example, by coupling condition variables with some kind of request results and supporting callbacks so the caller knows that getting the result will not block, while still supporting blocking waits if the caller so desires)."
I'm not entirely clear on the purpose of _yield(), but I'm assuming it's called to ensure that the event loop is run at least once before run() returns. Is there a way that the semantics of _yield() can be kept, but without relying on blocking condvars?