view release on metacpan or  search on metacpan

README  view on Meta::CPAN

                 $cv->end;
              };
           }

           $cv->end;

           ...

           my $results = $cv->recv;

        This code fragment supposedly pings a number of hosts and calls
        "send" after results for all then have have been gathered - in any
        order. To achieve this, the code issues a call to "begin" when it
        starts each ping request and calls "end" when it has received some
        result for it. Since "begin" and "end" only maintain a counter, the
        order in which results arrive is not relevant.

        There is an additional bracketing call to "begin" and "end" outside
        the loop, which serves two important purposes: first, it sets the
        callback to be called once the counter reaches 0, and second, it
        ensures that "send" is called even when "no" hosts are being pinged

lib/AnyEvent.pm  view on Meta::CPAN

         $cv->end;
      };
   }

   $cv->end;

   ...

   my $results = $cv->recv;

This code fragment supposedly pings a number of hosts and calls
C<send> after results for all then have have been gathered - in any
order. To achieve this, the code issues a call to C<begin> when it starts
each ping request and calls C<end> when it has received some result for
it. Since C<begin> and C<end> only maintain a counter, the order in which
results arrive is not relevant.

There is an additional bracketing call to C<begin> and C<end> outside the
loop, which serves two important purposes: first, it sets the callback
to be called once the counter reaches C<0>, and second, it ensures that
C<send> is called even when C<no> hosts are being pinged (the loop

lib/AnyEvent/Impl/POE.pm  view on Meta::CPAN

things I had to guess, cause unanticipated problems with this adaptor.

=item Fragile and inconsistent API

The POE API is extremely inconsistent - sometimes you have to pass a
session argument, sometimes it gets ignored, sometimes a session-specific
method must not use a session argument.

Error handling is sub-standard as well: even for programming mistakes,
POE does not C<croak> but, in most cases, just sets C<$!> or simply does
nothing at all, leading to fragile programs.

Sometimes registering a handler uses the "eventname, parameter" ordering
(timeouts), sometimes it is "parameter, eventname" (signals). There is
little consistency overall.

=item Lack of knowledge

   The IO::Poll event loop provides an alternative that theoretically
   scales better than select().