AnyEvent
view release on metacpan or search on metacpan
benchmark simply compares IO::Lambda with POE, and IO::Lambda looks
better (which shouldn't come as a surprise to anybody). As such, the
benchmark is fine, and mostly shows that the AnyEvent backend from
IO::Lambda isn't very optimal. But how would AnyEvent compare when used
without the extra baggage? To explore this, I wrote the equivalent
benchmark for AnyEvent.
The benchmark itself creates an echo-server, and then, for 500 times,
connects to the echo server, sends a line, waits for the reply, and then
creates the next connection. This is a rather bad benchmark, as it
doesn't test the efficiency of the framework or much non-blocking I/O,
but it is a benchmark nevertheless.
name runtime
Lambda/select 0.330 sec
+ optimized 0.122 sec
Lambda/AnyEvent 0.327 sec
+ optimized 0.138 sec
Raw sockets/select 0.077 sec
POE/select, components 0.662 sec
POE/select, raw sockets 0.226 sec
lib/AnyEvent.pm view on Meta::CPAN
could be misinterpreted to make AnyEvent look bad. In fact, the benchmark
simply compares IO::Lambda with POE, and IO::Lambda looks better (which
shouldn't come as a surprise to anybody). As such, the benchmark is
fine, and mostly shows that the AnyEvent backend from IO::Lambda isn't
very optimal. But how would AnyEvent compare when used without the extra
baggage? To explore this, I wrote the equivalent benchmark for AnyEvent.
The benchmark itself creates an echo-server, and then, for 500 times,
connects to the echo server, sends a line, waits for the reply, and then
creates the next connection. This is a rather bad benchmark, as it doesn't
test the efficiency of the framework or much non-blocking I/O, but it is a
benchmark nevertheless.
name runtime
Lambda/select 0.330 sec
+ optimized 0.122 sec
Lambda/AnyEvent 0.327 sec
+ optimized 0.138 sec
Raw sockets/select 0.077 sec
POE/select, components 0.662 sec
POE/select, raw sockets 0.226 sec
lib/AnyEvent/Intro.pod view on Meta::CPAN
The second part focuses on network programming using sockets, for which
AnyEvent offers a lot of support you can use, and a lot of workarounds
around portability quirks.
=head1 What is AnyEvent?
If you don't care for the whys and want to see code, skip this section!
AnyEvent is first of all just a framework to do event-based
programming. Typically such frameworks are an all-or-nothing thing: If you
use one such framework, you can't (easily, or even at all) use another in
the same program.
AnyEvent is different - it is a thin abstraction layer on top of other
event loops, just like DBI is an abstraction of many different database
APIs. Its main purpose is to move the choice of the underlying framework
(the event loop) from the module author to the program author using the
module.
That means you can write code that uses events to control what it
does, without forcing other code in the same program to use the same
underlying framework as you do - i.e. you can create a Perl module
that is event-based using AnyEvent, and users of that module can still
choose between using L<Gtk2>, L<Tk>, L<Event> (or run inside Irssi or
rxvt-unicode) or any other supported event loop. AnyEvent even comes with
its own pure-perl event loop implementation, so your code works regardless
of other modules that might or might not be installed. The latter is
important, as AnyEvent does not have any hard dependencies to other
modules, which makes it easy to install, for example, when you lack a C
compiler. No matter what environment, AnyEvent will just cope with it.
A typical limitation of existing Perl modules such as L<Net::IRC> is that
lib/AnyEvent/Intro.pod view on Meta::CPAN
=head1 Introduction to Event-Based Programming
So what exactly is programming using events? It quite simply means that
instead of your code actively waiting for something, such as the user
entering something on STDIN:
$| = 1; print "enter your name> ";
my $name = <STDIN>;
You instead tell your event framework to notify you in the event of some
data being available on STDIN, by using a callback mechanism:
use AnyEvent;
$| = 1; print "enter your name> ";
my $name;
my $wait_for_input = AnyEvent->io (
fh => \*STDIN, # which file handle to check
lib/AnyEvent/Intro.pod view on Meta::CPAN
Also, event-based programs need to block sometimes too, such as when
there is nothing to do, and everything is waiting for new events to
arrive.
In AnyEvent, this is done using condition variables. Condition variables
are named "condition variables" because they represent a condition that is
initially false and needs to be fulfilled.
You can also call them "merge points", "sync points", "rendezvous ports"
or even callbacks and many other things (and they are often called these
names in other frameworks). The important point is that you can create them
freely and later wait for them to become true.
Condition variables have two sides - one side is the "producer" of the
condition (whatever code detects and flags the condition), the other side
is the "consumer" (the code that waits for that condition).
In our example in the previous section, the producer is the event callback
and there is no consumer yet - let's change that right now:
use AnyEvent;
lib/AnyEvent/Intro.pod view on Meta::CPAN
undef $wait_for_input; # watcher no longer needed
print "your name is $name\n";
You can pass any number of arguments to C<send>, and every subsequent
call to C<recv> will return them.
=head2 The "main loop"
Most event-based frameworks have something called a "main loop" or "event
loop run function" or something similar.
Just like in C<recv> AnyEvent, these functions need to be called
eventually so that your event loop has a chance of actually looking for
the events you are interested in.
For example, in a L<Gtk2> program, the above example could also be written
like this:
use Gtk2 -init;
lib/AnyEvent/Intro.pod view on Meta::CPAN
In the example using condition variables, we used those to start waiting
for events, and in fact, condition variables are the solution:
my $quit_program = AnyEvent->condvar;
# create AnyEvent watchers (or not) here
$quit_program->recv;
If any of your watcher callbacks decide to quit (this is often
called an "unloop" in other frameworks), they can just call C<<
$quit_program->send >>. Of course, they could also decide not to and
call C<exit> instead, or they could decide never to quit (e.g. in a
long-running daemon program).
If you don't need some clean quit functionality and just want to run the
event loop, you can do this:
AnyEvent->condvar->recv;
And this is, in fact, the closest to the idea of a main loop run
lib/AnyEvent/Intro.pod view on Meta::CPAN
- event watchers and condition variables, L<AnyEvent::Socket> - basic
networking utilities, and L<AnyEvent::Handle> - a nice wrapper around
sockets.
You could either start coding stuff right away, look at those manual
pages for the gory details, or roam CPAN for other AnyEvent modules (such
as L<AnyEvent::IRC> or L<AnyEvent::HTTP>) to see more code examples (or
simply to use them).
If you need a protocol that doesn't have an implementation using AnyEvent,
remember that you can mix AnyEvent with one other event framework, such as
L<POE>, so you can always use AnyEvent for your own tasks plus modules of
one other event framework to fill any gaps.
And last not least, you could also look at L<Coro>, especially
L<Coro::AnyEvent>, to see how you can turn event-based programming from
callback style back to the usual imperative style (also called "inversion
of control" - AnyEvent calls I<you>, but Coro lets I<you> call AnyEvent).
=head1 Authors
Robin Redeker C<< <elmex at ta-sa.org> >>, Marc Lehmann <schmorp@schmorp.de>.
lib/AnyEvent/Log.pm view on Meta::CPAN
=head1 NAME
AnyEvent::Log - simple logging "framework"
=head1 SYNOPSIS
Simple uses:
use AnyEvent;
AE::log fatal => "No config found, cannot continue!"; # never returns
AE::log alert => "The battery died!";
AE::log crit => "The battery is too hot!";
lib/AnyEvent/Log.pm view on Meta::CPAN
# send all critical and higher priority messages to syslog,
# regardless of (most) other settings
$AnyEvent::Log::COLLECT->attach (new AnyEvent::Log::Ctx
level => "critical",
log_to_syslog => "user",
);
=head1 DESCRIPTION
This module implements a relatively simple "logging framework". It doesn't
attempt to be "the" logging solution or even "a" logging solution for
AnyEvent - AnyEvent simply creates logging messages internally, and this
module more or less exposes the mechanism, with some extra spiff to allow
using it from other modules as well.
Remember that the default verbosity level is C<4> (C<error>), so only
errors and more important messages will be logged, unless you set
C<PERL_ANYEVENT_VERBOSE> to a higher number before starting your program
(C<AE_VERBOSE=5> is recommended during development), or change the logging
level at runtime with something like:
( run in 0.564 second using v1.01-cache-2.11-cpan-df04353d9ac )