AnyEvent

 view release on metacpan or  search on metacpan

lib/AnyEvent/FAQ.pod  view on Meta::CPAN

Programmers new to event-based programming often forget that you can
actually do other stuff while "waiting" for an event to occur and
therefore forget to actually wait when they do not, in fact, have anything
else to do.

Here is an example:

   use AnyEvent;

   my $timer = AnyEvent->timer (after => 5, cb => sub { say "hi" });

The expectation might be for the program to print "hi" after 5 seconds
and then probably to exit. However, if you run this, your program will
exit almost instantly: Creating the timer does not wait for it, instead
the C<timer> method returns immediately and perl executes the rest of the
program. But there is nothing left to execute, so perl exits.

To force AnyEvent to wait for something, use a condvar:

   use AnyEvent;

lib/AnyEvent/Handle.pm  view on Meta::CPAN

         $hdl->destroy;
         $cv->send;
      };

   # send some request line
   $hdl->push_write ("getinfo\015\012");

   # read the response line
   $hdl->push_read (line => sub {
      my ($hdl, $line) = @_;
      say "got line <$line>";
      $cv->send;
   });

   $cv->recv;

=head1 DESCRIPTION

This is a helper module to make it easier to do event-based I/O
on stream-based filehandles (sockets, pipes, and other stream
things). Specifically, it doesn't work as expected on files, packet-based

lib/AnyEvent/Handle.pm  view on Meta::CPAN

=item chunk => $octets, $cb->($handle, $data)

Invoke the callback only once C<$octets> bytes have been read. Pass the
data read to the callback. The callback will never be called with less
data.

Example: read 2 bytes.

   $handle->push_read (chunk => 2, sub {
      say "yay " . unpack "H*", $_[1];
   });

=cut

register_read_type chunk => sub {
   my ($self, $cb, $len) = @_;

   sub {
      $len <= length $_[0]{rbuf} or return;
      $cb->($_[0], substr $_[0]{rbuf}, 0, $len, "");

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

=item One watcher per fd/event combo

POE, of course, suffers from the same bug as Tk and some other badly
designed event models in that it doesn't support multiple watchers per
fd/poll combo. The workaround is the same as with Tk: AnyEvent::Impl::POE
creates a separate file descriptor to hand to POE, which isn't fast and
certainly not nice to your resources.

Of course, without the workaround, POE also prints ugly messages again
that say the program *might* be buggy.

While this is not good to performance, at least regarding speed, with a
modern Linux kernel, the overhead is actually quite small.

=item Timing deficiencies

POE manages to not have a function that returns the current time. This is
extremely problematic, as POE can use different time functions, which can
differ by more than a second - and user code is left guessing which one is
used.

lib/AnyEvent/Socket.pm  view on Meta::CPAN

readable format.

Note that C<resolve_sockaddr>, while initially a more complex interface,
resolves host addresses, IDNs, service names and SRV records and gives you
an ordered list of socket addresses to try and should be preferred over
C<inet_aton>.

Example.

   inet_aton "www.google.com", my $cv = AE::cv;
   say unpack "H*", $_
      for $cv->recv;
   # => d155e363
   # => d155e367 etc.

   inet_aton "ipv6.google.com", my $cv = AE::cv;
   say unpack "H*", $_
      for $cv->recv;
   # => 20014860a00300000000000000000068

=cut

sub inet_aton {
   my ($name, $cb) = @_;

   if (my $ipn = &parse_ipv4) {
      $cb->($ipn);