Почему обратные вызовы AnyEvent::child никогда не запускаются, если события интервального таймера всегда готовы?

Интервал — это время между началом каждого обратного вызова таймера, т. е. не время между окончанием обратного вызова и началом следующего обратного вызова. Вы устанавливаете таймер с интервалом 0,5, и действие таймера — переход в спящий режим на одну секунду. Это означает, что после срабатывания таймера он будет немедленно запускаться снова и снова, потому что интервал всегда заканчивается после возврата таймера.

Таким образом, в зависимости от реализации цикла событий может случиться так, что никакие другие события не будут обрабатываться, потому что он занят запуском одного и того же таймера снова и снова. Я не знаю, какой базовый цикл событий вы используете (отметьте $AnyEvent::MODEL), но если вы посмотрите на исходный код AnyEvent::Loop (цикл для реализации на чистом Perl, т.е. модель AnyEvent::Impl::Perl) вы найдете следующий код:

   if (@timer && $timer[0][0] <= $MNOW) {
      do {
         my $timer = shift @timer;
         $timer->[1] && $timer->[1]($timer);
      } while @timer && $timer[0][0] <= $MNOW;

Как видите, он будет занят выполнением таймеров до тех пор, пока есть таймеры, которые необходимо запустить. И с вашей настройкой интервала (0,5) и поведением таймера (сон на одну секунду) всегда будет таймер, который нужно выполнить.

Если вместо этого вы измените свой таймер так, чтобы было место для обработки других событий, установив интервал больше, чем время блокировки (например, 2 секунды вместо 0,5), все работает нормально:

...
interval => 2,
cb => sub {
    sleep 1; # Simulated blocking operation. Sleep less than the interval!!
    say "timer";


...
timer
child
timer
timer

Обновите. Эту проблему можно решить с помощью исправлений, представленных в https://github.com/zbentley/AnyEvent-Impl-Perl-Improved/tree/io-starvation

Ответ @steffen-ulrich правильный, но указывает на очень ошибочное поведение в AnyEvent: поскольку нет базовой очереди событий, определенные виды событий, которые всегда сообщают «готово», могут на неопределенный срок опережать другие.

Вот обходной путь:

Для интервальных таймеров, которые всегда «готовы» из-за блокирующей операции, происходящей за пределами цикла событий, можно предотвратить голодание, объединяя интервальные вызовы в цепочку со следующим запуском цикла событий, например так:

use AnyEvent;

sub deferred_interval {
    my %args = @_;
    # Some silly wrangling to emulate AnyEvent's normal
    # "watchers are uninstalled when they are destroyed" behavior:
    ${$args{reference}} = 1;
    $args{oldref} //= delete($args{reference});
    return unless ${$args{oldref}};

    AnyEvent::postpone {
        ${$args{oldref}} = AnyEvent->timer(
            after => delete($args{after}) // $args{interval},
            cb => sub {
                $args{cb}->(@_);
                deferred_interval(%args);
            }
        );
    };

    return ${$args{oldref}};
}

# Start a timer that, at most once every 0.5 seconds, sleeps
# for 1 second, and then prints "timer":
my $w1; $w1 = deferred_interval(
    after => 0.1,
    reference => \$w2,  
    interval => 0.5,
    cb => sub {
        sleep 1; # Simulated blocking operation.
        say "timer";
    },
);

# Fork off a pid that waits for 1 second and then exits:
my $pid = fork();
if ( $pid == 0 ) {
    sleep 1;
    exit;
}

# Print "child" when the child process exits:
my $w1 = AnyEvent->child(
    pid => $pid,
    cb => sub {
        say "child";
    },
);

AnyEvent->condvar->recv;

Используя этот код, наблюдатель за дочерними процессами сработает более или менее вовремя, и интервал будет продолжать срабатывать. Компромисс заключается в том, что каждый интервальный таймер запускается только после завершения каждого блокирующего обратного вызова. Учитывая время интервала I и время выполнения блокирующего обратного вызова B, этот подход будет запускать событие интервала примерно каждые I + B секунды, а предыдущий подход из вопроса займет min(I,B) секунд (за счет потенциального голодания).

Я думаю, что многих головных болей здесь можно было бы избежать, если бы у AnyEvent была резервная очередь (многие распространенные циклы обработки событий используют этот подход для предотвращения ситуаций, в точности подобных этой), или если бы реализация AnyEvent::postpone установила эмиттер событий, подобный NextTick. запускаться только после того, как все остальные эмиттеры будут проверены на наличие событий.