[ViewVC] Diff of: cvs/AnyEvent/README

Comparing AnyEvent/README (file contents):
Revision 1.43 by root, Thu Jul 9 08:37:06 2009 UTC vs.
Revision 1.61 by root, Wed Apr 28 14:15:55 2010 UTC

 NAME
-    AnyEvent - provide framework for multiple event loops
+    AnyEvent - the DBI of event loop programming
-    EV, Event, Glib, Tk, Perl, Event::Lib, Qt and POE are various supported
+    EV, Event, Glib, Tk, Perl, Event::Lib, Irssi, rxvt-unicode, IO::Async,
-    event loops.
+    Qt and POE are various supported event loops/environments.
 SYNOPSIS
        use AnyEvent;
+       # if you prefer function calls, look at the L<AE> manpage for
+       # an alternative API.
-       # file descriptor readable
+       # file handle or descriptor readable
        my $w = AnyEvent->io (fh => $fh, poll => "r", cb => sub { ...  });
        # one-shot or repeating timers
        my $w = AnyEvent->timer (after => $seconds, cb => sub { ...  });
        my $w = AnyEvent->timer (after => $seconds, interval => $seconds, cb => ...
 INTRODUCTION/TUTORIAL
     This manpage is mainly a reference manual. If you are interested in a
     tutorial or some gentle introduction, have a look at the AnyEvent::Intro
     manpage.
+SUPPORT
+    There is a mailinglist for discussing all things AnyEvent, and an IRC
+    channel, too.
+    See the AnyEvent project page at the Schmorpforge Ta-Sa Software
+    Repository, at <http://anyevent.schmorp.de>, for more info.
 WHY YOU SHOULD USE THIS MODULE (OR NOT)
     Glib, POE, IO::Async, Event... CPAN offers event models by the dozen
     nowadays. So what is different about AnyEvent?
     Note that "my $w; $w =" combination. This is necessary because in Perl,
     my variables are only visible after the statement in which they are
     declared.
   I/O WATCHERS
+       $w = AnyEvent->io (
+          fh   => <filehandle_or_fileno>,
+          poll => <"r" or "w">,
+          cb   => <callback>,
+       );
     You can create an I/O watcher by calling the "AnyEvent->io" method with
     the following mandatory key-value pairs as arguments:
     "fh" is the Perl *file handle* (or a naked file descriptor) to watch for
     events (AnyEvent might or might not keep a reference to this file
           warn "read: $input\n";
           undef $w;
        });
   TIME WATCHERS
+       $w = AnyEvent->timer (after => <seconds>, cb => <callback>);
+       $w = AnyEvent->timer (
+          after    => <fractional_seconds>,
+          interval => <fractional_seconds>,
+          cb       => <callback>,
+       );
     You can create a time watcher by calling the "AnyEvent->timer" method
     with the following mandatory arguments:
     "after" specifies after how many seconds (fractional values are
     supported) the callback should be invoked. "cb" is the callback to
         time, which might affect timers and time-outs.
         When this is the case, you can call this method, which will update
         the event loop's idea of "current time".
+        A typical example would be a script in a web server (e.g.
+        "mod_perl") - when mod_perl executes the script, then the event loop
+        will have the wrong idea about the "current time" (being potentially
+        far in the past, when the script ran the last time). In that case
+        you should arrange a call to "AnyEvent->now_update" each time the
+        web server process wakes up again (e.g. at the start of your script,
+        or in a handler).
         Note that updating the time *might* cause some events to be handled.
   SIGNAL WATCHERS
+       $w = AnyEvent->signal (signal => <uppercase_signal_name>, cb => <callback>);
     You can watch for signals using a signal watcher, "signal" is the signal
     *name* in uppercase and without any "SIG" prefix, "cb" is the Perl
     callback to be invoked whenever a signal occurs.
     Although the callback might get passed parameters, their value and
     invocation, and callback invocation will be synchronous. Synchronous
     means that it might take a while until the signal gets handled by the
     process, but it is guaranteed not to interrupt any other callbacks.
     The main advantage of using these watchers is that you can share a
-    signal between multiple watchers.
+    signal between multiple watchers, and AnyEvent will ensure that signals
+    will not interrupt your program at bad times.
-    This watcher might use %SIG, so programs overwriting those signals
+    This watcher might use %SIG (depending on the event loop used), so
-    directly will likely not work correctly.
+    programs overwriting those signals directly will likely not work
+    correctly.
     Example: exit on SIGINT
        my $w = AnyEvent->signal (signal => "INT", cb => sub { exit 1 });
+   Restart Behaviour
+    While restart behaviour is up to the event loop implementation, most
+    will not restart syscalls (that includes Async::Interrupt and AnyEvent's
+    pure perl implementation).
+   Safe/Unsafe Signals
+    Perl signals can be either "safe" (synchronous to opcode handling) or
+    "unsafe" (asynchronous) - the former might get delayed indefinitely, the
+    latter might corrupt your memory.
+    AnyEvent signal handlers are, in addition, synchronous to the event
+    loop, i.e. they will not interrupt your running perl program but will
+    only be called as part of the normal event handling (just like timer,
+    I/O etc. callbacks, too).
+   Signal Races, Delays and Workarounds
+    Many event loops (e.g. Glib, Tk, Qt, IO::Async) do not support attaching
+    callbacks to signals in a generic way, which is a pity, as you cannot do
+    race-free signal handling in perl, requiring C libraries for this.
+    AnyEvent will try to do it's best, which means in some cases, signals
+    will be delayed. The maximum time a signal might be delayed is specified
+    in $AnyEvent::MAX_SIGNAL_LATENCY (default: 10 seconds). This variable
+    can be changed only before the first signal watcher is created, and
+    should be left alone otherwise. This variable determines how often
+    AnyEvent polls for signals (in case a wake-up was missed). Higher values
+    will cause fewer spurious wake-ups, which is better for power and CPU
+    saving.
+    All these problems can be avoided by installing the optional
+    Async::Interrupt module, which works with most event loops. It will not
+    work with inherently broken event loops such as Event or Event::Lib (and
+    not with POE currently, as POE does it's own workaround with one-second
+    latency). For those, you just have to suffer the delays.
   CHILD PROCESS WATCHERS
+       $w = AnyEvent->child (pid => <process id>, cb => <callback>);
     You can also watch on a child process exit and catch its exit status.
-    The child process is specified by the "pid" argument (if set to 0, it
+    The child process is specified by the "pid" argument (one some backends,
-    watches for any child process exit). The watcher will triggered only
+    using 0 watches for any child process exit, on others this will croak).
-    when the child process has finished and an exit status is available, not
+    The watcher will be triggered only when the child process has finished
-    on any trace events (stopped/continued).
+    and an exit status is available, not on any trace events
+    (stopped/continued).
     The callback will be called with the pid and exit status (as returned by
     waitpid), so unlike other watcher types, you *can* rely on child watcher
     callback arguments.
     This means you cannot create a child watcher as the very first thing in
     an AnyEvent program, you *have* to create at least one watcher before
     you "fork" the child (alternatively, you can call "AnyEvent::detect").
+    As most event loops do not support waiting for child events, they will
+    be emulated by AnyEvent in most cases, in which the latency and race
+    problems mentioned in the description of signal watchers apply.
     Example: fork a process and wait for it
        my $done = AnyEvent->condvar;
-       my $pid = fork or exit 5;
+   my $pid = fork or exit 5;
-       my $w = AnyEvent->child (
+   my $w = AnyEvent->child (
           pid => $pid,
           cb  => sub {
              my ($pid, $status) = @_;
              warn "pid $pid exited with status $status";
              $done->send;
           },
        );
-       # do something else, then wait for process exit
+   # do something else, then wait for process exit
        $done->recv;
   IDLE WATCHERS
-    Sometimes there is a need to do something, but it is not so important to
+       $w = AnyEvent->idle (cb => <callback>);
-    do it instantly, but only when there is nothing better to do. This
-    "nothing better to do" is usually defined to be "no other events need
-    attention by the event loop".
-    Idle watchers ideally get invoked when the event loop has nothing better
+    Repeatedly invoke the callback after the process becomes idle, until
-    to do, just before it would block the process to wait for new events.
+    either the watcher is destroyed or new events have been detected.
-    Instead of blocking, the idle watcher is invoked.
-    Most event loops unfortunately do not really support idle watchers (only
+    Idle watchers are useful when there is a need to do something, but it is
+    not so important (or wise) to do it instantly. The callback will be
+    invoked only when there is "nothing better to do", which is usually
+    defined as "all outstanding events have been handled and no new events
+    have been detected". That means that idle watchers ideally get invoked
+    when the event loop has just polled for new events but none have been
+    detected. Instead of blocking to wait for more events, the idle watchers
+    will be invoked.
+    Unfortunately, most event loops do not really support idle watchers
-    EV, Event and Glib do it in a usable fashion) - for the rest, AnyEvent
+    (only EV, Event and Glib do it in a usable fashion) - for the rest,
-    will simply call the callback "from time to time".
+    AnyEvent will simply call the callback "from time to time".
     Example: read lines from STDIN, but only process them when the program
     is otherwise idle:
        my @lines; # read data
              }
           });
        });
   CONDITION VARIABLES
+       $cv = AnyEvent->condvar;
+       $cv->send (<list>);
+       my @res = $cv->recv;
     If you are familiar with some event loops you will know that all of them
     require you to run some blocking "loop", "run" or similar function that
     will actively watch for new events and call your callbacks.
-    AnyEvent is different, it expects somebody else to run the event loop
+    AnyEvent is slightly different: it expects somebody else to run the
-    and will only block when necessary (usually when told by the user).
+    event loop and will only block when necessary (usually when told by the
+    user).
     The instrument to do that is called a "condition variable", so called
     because they represent a condition that must become true.
+    Now is probably a good time to look at the examples further below.
     Condition variables can be created by calling the "AnyEvent->condvar"
     method, usually without arguments. The only argument pair allowed is
     "cb", which specifies a callback to be called when the condition
     variable becomes true, with the condition variable as the first argument
     (but not the results).
     After creation, the condition variable is "false" until it becomes
     Condition variables are similar to callbacks, except that you can
     optionally wait for them. They can also be called merge points - points
     in time where multiple outstanding events have been processed. And yet
     another way to call them is transactions - each condition variable can
     be used to represent a transaction, which finishes at some point and
-    delivers a result.
+    delivers a result. And yet some people know them as "futures" - a
+    promise to compute/deliver something that you can wait for.
     Condition variables are very useful to signal that something has
     finished, for example, if you write a module that does asynchronous http
     requests, then a condition variable would be the ideal candidate to
     signal the availability of results. The user can either act when the
     which eventually calls "-> send", and the "consumer side", which waits
     for the send to occur.
     Example: wait for a timer.
-       # wait till the result is ready
+       # condition: "wait till the timer is fired"
-       my $result_ready = AnyEvent->condvar;
+       my $timer_fired = AnyEvent->condvar;
-       # do something such as adding a timer
+       # create the timer - we could wait for, say
-       # or socket watcher the calls $result_ready->send
+       # a handle becomign ready, or even an
-       # when the "result" is ready.
+       # AnyEvent::HTTP request to finish, but
        # in this case, we simply use a timer:
        my $w = AnyEvent->timer (
           after => 1,
-          cb    => sub { $result_ready->send },
+          cb    => sub { $timer_fired->send },
        );
        # this "blocks" (while handling events) till the callback
-       # calls send
+       # calls ->send
-       $result_ready->recv;
+       $timer_fired->recv;
     Example: wait for a timer, but take advantage of the fact that condition
-    variables are also code references.
+    variables are also callable directly.
        my $done = AnyEvent->condvar;
        my $delay = AnyEvent->timer (after => 5, cb => $done);
        $done->recv;
        ...
        my @info = $couchdb->info->recv;
-    And this is how you would just ste a callback to be called whenever the
+    And this is how you would just set a callback to be called whenever the
     results are available:
        $couchdb->info->cb (sub {
           my @info = $_[0]->recv;
        });
         Any arguments passed to the "send" call will be returned by all
         future "->recv" calls.
         Condition variables are overloaded so one can call them directly (as
-        a code reference). Calling them directly is the same as calling
+        if they were a code reference). Calling them directly is the same as
-        "send". Note, however, that many C-based event loops do not handle
+        calling "send".
-        overloading, so as tempting as it may be, passing a condition
-        variable instead of a callback does not work. Both the pure perl and
-        EV loops support overloading, however, as well as all functions that
-        use perl to invoke a callback (as in AnyEvent::Socket and
-        AnyEvent::DNS for example).
     $cv->croak ($error)
         Similar to send, but causes all call's to "->recv" to invoke
         "Carp::croak" with the given error message/object/scalar.
         This can be used to signal any errors to the condition variable
-        user/consumer.
+        user/consumer. Doing it this way instead of calling "croak" directly
+        delays the error detetcion, but has the overwhelmign advantage that
+        it diagnoses the error at the place where the result is expected,
+        and not deep in some event clalback without connection to the actual
+        code causing the problem.
     $cv->begin ([group callback])
     $cv->end
         These two methods can be used to combine many transactions/events
         into one. For example, a function that pings many hosts in parallel
         might want to use a condition variable for the whole process.
         Every call to "->begin" will increment a counter, and every call to
         "->end" will decrement it. If the counter reaches 0 in "->end", the
-        (last) callback passed to "begin" will be executed. That callback is
+        (last) callback passed to "begin" will be executed, passing the
-        *supposed* to call "->send", but that is not required. If no
+        condvar as first argument. That callback is *supposed* to call
+        "->send", but that is not required. If no group callback was set,
-        callback was set, "send" will be called without any arguments.
+        "send" will be called without any arguments.
         You can think of "$cv->send" giving you an OR condition (one call
         sends), while "$cv->begin" and "$cv->end" giving you an AND
         condition (all "begin" calls must be "end"'ed before the condvar
         sends).
         that are begung can potentially be zero:
            my $cv = AnyEvent->condvar;
            my %result;
-           $cv->begin (sub { $cv->send (\%result) });
+           $cv->begin (sub { shift->send (\%result) });
            for my $host (@list_of_hosts) {
               $cv->begin;
               ping_host_then_call_callback $host, sub {
                  $result{$host} = ...;
         function will call "croak".
         In list context, all parameters passed to "send" will be returned,
         in scalar context only the first one will be returned.
+        Note that doing a blocking wait in a callback is not supported by
+        any event loop, that is, recursive invocation of a blocking "->recv"
+        is not allowed, and the "recv" call will "croak" if such a condition
+        is detected. This condition can be slightly loosened by using
+        Coro::AnyEvent, which allows you to do a blocking "->recv" from any
+        thread that doesn't run the event loop itself.
         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*, but let
+        using this from a module, never require a blocking wait*. Instead,
-        the caller decide whether the call will block or not (for example,
+        let the caller decide whether the call will block or not (for
-        by coupling condition variables with some kind of request results
+        example, by coupling condition variables with some kind of request
-        and supporting callbacks so the caller knows that getting the result
+        results and supporting callbacks so the caller knows that getting
-        will not block, while still supporting blocking waits if the caller
+        the result will not block, while still supporting blocking waits if
-        so desires).
+        the caller so desires).
-        Another reason *never* to "->recv" in a module is that you cannot
-        sensibly have two "->recv"'s in parallel, as that would require
-        multiple interpreters or coroutines/threads, none of which
-        "AnyEvent" can supply.
-        The Coro module, however, *can* and *does* supply coroutines and, in
-        fact, Coro::AnyEvent replaces AnyEvent's condvars by coroutine-safe
-        versions and also integrates coroutines into AnyEvent, making
-        blocking "->recv" calls perfectly safe as long as they are done from
-        another coroutine (one that doesn't run the event loop).
         You can ensure that "-recv" never blocks by setting a callback and
         only calling "->recv" from within that callback (or at a later
         time). This will work even when the event loop does not support
         blocking waits otherwise.
     $cb = $cv->cb ($cb->($cv))
         This is a mutator function that returns the callback set and
         optionally replaces it before doing so.
-        The callback will be called when the condition becomes "true", i.e.
+        The callback will be called when the condition becomes (or already
-        when "send" or "croak" are called, with the only argument being the
+        was) "true", i.e. when "send" or "croak" are called (or were
-        condition variable itself. Calling "recv" inside the callback or at
+        called), with the only argument being the condition variable itself.
+        Calling "recv" inside the callback or at any later time is
-        any later time is guaranteed not to block.
+        guaranteed not to block.
 SUPPORTED EVENT LOOPS/BACKENDS
     The available backend classes are (every class has its own manpage):
     Backends that are autoprobed when no other event loop can be found.
         EV is the preferred backend when no other event loop seems to be in
-        use. If EV is not installed, then AnyEvent will try Event, and,
+        use. If EV is not installed, then AnyEvent will fall back to its own
-        failing that, will fall back to its own pure-perl implementation,
+        pure-perl implementation, which is available everywhere as it comes
-        which is available everywhere as it comes with AnyEvent itself.
+        with AnyEvent itself.
            AnyEvent::Impl::EV        based on EV (interface to libev, best choice).
-           AnyEvent::Impl::Event     based on Event, very stable, few glitches.
            AnyEvent::Impl::Perl      pure-perl implementation, fast and portable.
     Backends that are transparently being picked up when they are used.
         These will be used when they are currently loaded when the first
         watcher is created, in which case it is assumed that the application
         is using them. This means that AnyEvent will automatically pick the
         right backend when the main program loads an event module before
         anything starts to create watchers. Nothing special needs to be done
         by the main program.
+           AnyEvent::Impl::Event     based on Event, very stable, few glitches.
            AnyEvent::Impl::Glib      based on Glib, slow but very stable.
            AnyEvent::Impl::Tk        based on Tk, very broken.
            AnyEvent::Impl::EventLib  based on Event::Lib, leaks memory and worse.
            AnyEvent::Impl::POE       based on POE, very slow, some limitations.
+           AnyEvent::Impl::Irssi     used when running within irssi.
     Backends with special needs.
         Qt requires the Qt::Application to be instantiated first, but will
         otherwise be picked up automatically. As long as the main program
         instantiates the application before any AnyEvent watchers are
         creates and installs the global IO::AIO watcher in a "post_detect"
         block to avoid autodetecting the event module at load time.
         If called in scalar or list context, then it creates and returns an
         object that automatically removes the callback again when it is
+        destroyed (or "undef" when the hook was immediately executed). See
-        destroyed. See Coro::BDB for a case where this is useful.
+        AnyEvent::AIO for a case where this is useful.
+        Example: Create a watcher for the IO::AIO module and store it in
+        $WATCHER. Only do so after the event loop is initialised, though.
+           our WATCHER;
+           my $guard = AnyEvent::post_detect {
+              $WATCHER = AnyEvent->io (fh => IO::AIO::poll_fileno, poll => 'r', cb => \&IO::AIO::poll_cb);
+           };
+           # the ||= is important in case post_detect immediately runs the block,
+           # as to not clobber the newly-created watcher. assigning both watcher and
+           # post_detect guard to the same variable has the advantage of users being
+           # able to just C<undef $WATCHER> if the watcher causes them grief.
+           $WATCHER ||= $guard;
     @AnyEvent::post_detect
         If there are any code references in this array (you can "push" to it
         before or after loading AnyEvent), then they will called directly
         after the event loop has been chosen.
         You should check $AnyEvent::MODEL before adding to this array,
         though: if it is defined then the event loop has already been
         detected, and the array will be ignored.
         Best use "AnyEvent::post_detect { BLOCK }" when your application
-        allows it,as it takes care of these details.
+        allows it, as it takes care of these details.
         This variable is mainly useful for modules that can do something
         useful when AnyEvent is used and thus want to know when it is
         initialised, but do not need to even load it by default. This array
         provides the means to hook into AnyEvent passively, without loading
         it.
+        Example: To load Coro::AnyEvent whenever Coro and AnyEvent are used
+        together, you could put this into Coro (this is the actual code used
+        by Coro to accomplish this):
+           if (defined $AnyEvent::MODEL) {
+              # AnyEvent already initialised, so load Coro::AnyEvent
+              require Coro::AnyEvent;
+           } else {
+              # AnyEvent not yet initialised, so make sure to load Coro::AnyEvent
+              # as soon as it is
+              push @AnyEvent::post_detect, sub { require Coro::AnyEvent };
+           }
 WHAT TO DO IN A MODULE
     As a module author, you should "use AnyEvent" and call AnyEvent methods
     freely, but you should not load a specific event module or rely on it.
         High level API for event-based execution flow control.
     Coro
         Has special support for AnyEvent via Coro::AnyEvent.
+SIMPLIFIED AE API
+    Starting with version 5.0, AnyEvent officially supports a second, much
+    simpler, API that is designed to reduce the calling, typing and memory
+    overhead by using function call syntax and a fixed number of parameters.
+    See the AE manpage for details.
 ERROR AND EXCEPTION HANDLING
     In general, AnyEvent does not do any error handling - it relies on the
     caller to do that if required. The AnyEvent::Strict module (see also the
     "PERL_ANYEVENT_STRICT" environment variable, below) provides strict
     checking of all AnyEvent methods, however, which is highly useful during
         by "PERL_ANYEVENT_MODEL".
         When set to 2 or higher, cause AnyEvent to report to STDERR which
         event model it chooses.
+        When set to 8 or higher, then AnyEvent will report extra information
+        on which optional modules it loads and how it implements certain
+        features.
     "PERL_ANYEVENT_STRICT"
         AnyEvent does not do much argument checking by default, as thorough
         argument checking is very costly. Setting this variable to a true
         value will cause AnyEvent to load "AnyEvent::Strict" and then to
         thoroughly check the arguments passed to most method calls. If it
         finds any problems, it will croak.
         In other words, enables "strict" mode.
-        Unlike "use strict", it is definitely recommended to keep it off in
+        Unlike "use strict" (or it's modern cousin, "use common::sense", it
-        production. Keeping "PERL_ANYEVENT_STRICT=1" in your environment
+        is definitely recommended to keep it off in production. Keeping
+        "PERL_ANYEVENT_STRICT=1" in your environment while developing
-        while developing programs can be very useful, however.
+        programs can be very useful, however.
     "PERL_ANYEVENT_MODEL"
         This can be used to specify the event model to be used by AnyEvent,
         before auto detection and -probing kicks in. It must be a string
         consisting entirely of ASCII letters. The string "AnyEvent::Impl::"
     "PERL_ANYEVENT_CA_FILE", "PERL_ANYEVENT_CA_PATH".
         When neither "ca_file" nor "ca_path" was specified during
         AnyEvent::TLS context creation, and either of these environment
         variables exist, they will be used to specify CA certificate
         locations instead of a system-dependent default.
+    "PERL_ANYEVENT_AVOID_GUARD" and "PERL_ANYEVENT_AVOID_ASYNC_INTERRUPT"
+        When these are set to 1, then the respective modules are not loaded.
+        Mostly good for testing AnyEvent itself.
 SUPPLYING YOUR OWN EVENT MODEL INTERFACE
     This is an advanced topic that you do not normally need to use AnyEvent
     in a module. This section is only of use to event loop authors who want
     to provide AnyEvent compatibility.
              warn "read: $input\n";       # output what has been read
              $cv->send if $input =~ /^q/i; # quit program if /^q/i
           },
        );
-       my $time_watcher; # can only be used once
-       sub new_timer {
-          $timer = AnyEvent->timer (after => 1, cb => sub {
+       my $time_watcher = AnyEvent->timer (after => 1, interval => 1, cb => sub {
-             warn "timeout\n"; # print 'timeout' about every second
+          warn "timeout\n"; # print 'timeout' at most every second
-             &new_timer; # and restart the time
-          });
-       }
+       });
-       new_timer; # create first timer
        $cv->recv; # wait until user enters /^q/i
 REAL-WORLD EXAMPLE
     Consider the Net::FCP module. It features (among others) the following
     The actual code goes further and collects all errors ("die"s,
     exceptions) that occurred during request processing. The "result" method
     detects whether an exception as thrown (it is stored inside the $txn
     object) and just throws the exception, which means connection errors and
-    other problems get reported tot he code that tries to use the result,
+    other problems get reported to the code that tries to use the result,
     not in a random callback.
     All of this enables the following usage styles:
     1. Blocking:
     through AnyEvent. The benchmark creates a lot of timers (with a zero
     timeout) and I/O watchers (watching STDOUT, a pty, to become writable,
     which it is), lets them fire exactly once and destroys them again.
     Source code for this benchmark is found as eg/bench in the AnyEvent
-    distribution.
+    distribution. It uses the AE interface, which makes a real difference
+    for the EV and Perl backends only.
    Explanation of the columns
     *watcher* is the number of event watchers created/destroyed. Since
     different event models feature vastly different performances, each event
     loop was given a number of watchers so that overall runtime is
     *destroy* is the time, in microseconds, that it takes to destroy a
     single watcher.
    Results
               name watchers bytes create invoke destroy comment
-             EV/EV   400000   224   0.47   0.35    0.27 EV native interface
+             EV/EV   100000   223   0.47   0.43    0.27 EV native interface
-            EV/Any   100000   224   2.88   0.34    0.27 EV + AnyEvent watchers
+            EV/Any   100000   223   0.48   0.42    0.26 EV + AnyEvent watchers
-        CoroEV/Any   100000   224   2.85   0.35    0.28 coroutines + Coro::Signal
+      Coro::EV/Any   100000   223   0.47   0.42    0.26 coroutines + Coro::Signal
-          Perl/Any   100000   452   4.13   0.73    0.95 pure perl implementation
+          Perl/Any   100000   431   2.70   0.74    0.92 pure perl implementation
-       Event/Event    16000   517  32.20  31.80    0.81 Event native interface
+       Event/Event    16000   516  31.16  31.84    0.82 Event native interface
-         Event/Any    16000   590  35.85  31.55    1.06 Event + AnyEvent watchers
+         Event/Any    16000  1203  42.61  34.79    1.80 Event + AnyEvent watchers
-       IOAsync/Any    16000   989  38.10  32.77   11.13 via IO::Async::Loop::IO_Poll
+       IOAsync/Any    16000  1911  41.92  27.45   16.81 via IO::Async::Loop::IO_Poll
-       IOAsync/Any    16000   990  37.59  29.50   10.61 via IO::Async::Loop::Epoll
+       IOAsync/Any    16000  1726  40.69  26.37   15.25 via IO::Async::Loop::Epoll
-          Glib/Any    16000  1357 102.33  12.31   51.00 quadratic behaviour
+          Glib/Any    16000  1118  89.00  12.57   51.17 quadratic behaviour
-            Tk/Any     2000  1860  27.20  66.31   14.00 SEGV with >> 2000 watchers
+            Tk/Any     2000  1346  20.96  10.75    8.00 SEGV with >> 2000 watchers
-         POE/Event     2000  6328 109.99 751.67   14.02 via POE::Loop::Event
+           POE/Any     2000  6951 108.97 795.32   14.24 via POE::Loop::Event
-        POE/Select     2000  6027  94.54 809.13  579.80 via POE::Loop::Select
+           POE/Any     2000  6648  94.79 774.40  575.51 via POE::Loop::Select
    Discussion
     The benchmark does *not* measure scalability of the event loop very
     well. For example, a select-based event loop (such as the pure perl one)
     can never compete with an event loop that uses epoll when the number of
     benchmark machine, handling an event takes roughly 1600 CPU cycles with
     EV, 3100 CPU cycles with AnyEvent's pure perl loop and almost 3000000
     CPU cycles with POE.
     "EV" is the sole leader regarding speed and memory use, which are both
-    maximal/minimal, respectively. Even when going through AnyEvent, it uses
+    maximal/minimal, respectively. When using the AE API there is zero
+    overhead (when going through the AnyEvent API create is about 5-6 times
+    slower, with other times being equal, so still uses far less memory than
-    far less memory than any other event loop and is still faster than Event
+    any other event loop and is still faster than Event natively).
-    natively.
     The pure perl implementation is hit in a few sweet spots (both the
     constant timeout and the use of a single fd hit optimisations in the
     perl interpreter and the backend itself). Nevertheless this shows that
     it adds very little overhead in itself. Like any select-based backend
     In this benchmark, we use 10000 socket pairs (20000 sockets), of which
     100 (1%) are active. This mirrors the activity of large servers with
     many connections, most of which are idle at any one point in time.
     Source code for this benchmark is found as eg/bench2 in the AnyEvent
-    distribution.
+    distribution. It uses the AE interface, which makes a real difference
+    for the EV and Perl backends only.
    Explanation of the columns
     *sockets* is the number of sockets, and twice the number of "servers"
     (as each server has a read and write socket end).
     forwarding it to another server. This includes deleting the old timeout
     and creating a new one that moves the timeout into the future.
    Results
          name sockets create  request
-           EV   20000  69.01    11.16
+           EV   20000  62.66     7.99
-         Perl   20000  73.32    35.87
+         Perl   20000  68.32    32.64
-      IOAsync   20000 157.00    98.14 epoll
+      IOAsync   20000 174.06   101.15 epoll
-      IOAsync   20000 159.31   616.06 poll
+      IOAsync   20000 174.67   610.84 poll
-        Event   20000 212.62   257.32
+        Event   20000 202.69   242.91
-         Glib   20000 651.16  1896.30
+         Glib   20000 557.01  1689.52
-          POE   20000 349.67 12317.24 uses POE::Loop::Event
+          POE   20000 341.54 12086.32 uses POE::Loop::Event
    Discussion
     This benchmark *does* measure scalability and overall performance of the
     particular event loop.
     As you can see, the AnyEvent + EV combination even beats the
     hand-optimised "raw sockets benchmark", while AnyEvent + its pure perl
     backend easily beats IO::Lambda and POE.
     And even the 100% non-blocking version written using the high-level (and
-    slow :) AnyEvent::Handle abstraction beats both POE and IO::Lambda by a
+    slow :) AnyEvent::Handle abstraction beats both POE and IO::Lambda
-    large margin, even though it does all of DNS, tcp-connect and socket I/O
+    higher level ("unoptimised") abstractions by a large margin, even though
-    in a non-blocking way.
+    it does all of DNS, tcp-connect and socket I/O in a non-blocking way.
     The two AnyEvent benchmarks programs can be found as eg/ae0.pl and
     eg/ae2.pl in the AnyEvent distribution, the remaining benchmarks are
-    part of the IO::lambda distribution and were used without any changes.
+    part of the IO::Lambda distribution and were used without any changes.
 SIGNALS
     AnyEvent currently installs handlers for these signals:
     SIGCHLD
         A handler for "SIGCHLD" is installed by AnyEvent's child watcher
         emulation for event loops that do not support them natively. Also,
         some event loops install a similar handler.
-        If, when AnyEvent is loaded, SIGCHLD is set to IGNORE, then AnyEvent
+        Additionally, when AnyEvent is loaded and SIGCHLD is set to IGNORE,
-        will reset it to default, to avoid losing child exit statuses.
+        then AnyEvent will reset it to default, to avoid losing child exit
+        statuses.
     SIGPIPE
         A no-op handler is installed for "SIGPIPE" when $SIG{PIPE} is
         "undef" when AnyEvent gets loaded.
         it is that this way, the handler will be restored to defaults on
         exec.
         Feel free to install your own handler, or reset it to defaults.
+RECOMMENDED/OPTIONAL MODULES
+    One of AnyEvent's main goals is to be 100% Pure-Perl(tm): only perl (and
+    it's built-in modules) are required to use it.
+    That does not mean that AnyEvent won't take advantage of some additional
+    modules if they are installed.
+    This section explains which additional modules will be used, and how
+    they affect AnyEvent's operation.
+    Async::Interrupt
+        This slightly arcane module is used to implement fast signal
+        handling: To my knowledge, there is no way to do completely
+        race-free and quick signal handling in pure perl. To ensure that
+        signals still get delivered, AnyEvent will start an interval timer
+        to wake up perl (and catch the signals) with some delay (default is
+        10 seconds, look for $AnyEvent::MAX_SIGNAL_LATENCY).
+        If this module is available, then it will be used to implement
+        signal catching, which means that signals will not be delayed, and
+        the event loop will not be interrupted regularly, which is more
+        efficient (and good for battery life on laptops).
+        This affects not just the pure-perl event loop, but also other event
+        loops that have no signal handling on their own (e.g. Glib, Tk, Qt).
+        Some event loops (POE, Event, Event::Lib) offer signal watchers
+        natively, and either employ their own workarounds (POE) or use
+        AnyEvent's workaround (using $AnyEvent::MAX_SIGNAL_LATENCY).
+        Installing Async::Interrupt does nothing for those backends.
+    EV  This module isn't really "optional", as it is simply one of the
+        backend event loops that AnyEvent can use. However, it is simply the
+        best event loop available in terms of features, speed and stability:
+        It supports the AnyEvent API optimally, implements all the watcher
+        types in XS, does automatic timer adjustments even when no monotonic
+        clock is available, can take avdantage of advanced kernel interfaces
+        such as "epoll" and "kqueue", and is the fastest backend *by far*.
+        You can even embed Glib/Gtk2 in it (or vice versa, see EV::Glib and
+        Glib::EV).
+        If you only use backends that rely on another event loop (e.g.
+        "Tk"), then this module will do nothing for you.
+    Guard
+        The guard module, when used, will be used to implement
+        "AnyEvent::Util::guard". This speeds up guards considerably (and
+        uses a lot less memory), but otherwise doesn't affect guard
+        operation much. It is purely used for performance.
+    JSON and JSON::XS
+        One of these modules is required when you want to read or write JSON
+        data via AnyEvent::Handle. JSON is also written in pure-perl, but
+        can take advantage of the ultra-high-speed JSON::XS module when it
+        is installed.
+    Net::SSLeay
+        Implementing TLS/SSL in Perl is certainly interesting, but not very
+        worthwhile: If this module is installed, then AnyEvent::Handle (with
+        the help of AnyEvent::TLS), gains the ability to do TLS/SSL.
+    Time::HiRes
+        This module is part of perl since release 5.008. It will be used
+        when the chosen event library does not come with a timing source on
+        it's own. The pure-perl event loop (AnyEvent::Impl::Perl) will
+        additionally use it to try to use a monotonic clock for timing
+        stability.
 FORK
     Most event libraries are not fork-safe. The ones who are usually are
-    because they rely on inefficient but fork-safe "select" or "poll" calls.
+    because they rely on inefficient but fork-safe "select" or "poll" calls
-    Only EV is fully fork-aware.
+    - higher performance APIs such as BSD's kqueue or the dreaded Linux
+    epoll are usually badly thought-out hacks that are incompatible with
+    fork in one way or another. Only EV is fully fork-aware and ensures that
+    you continue event-processing in both parent and child (or both, if you
+    know what you are doing).
+    This means that, in general, you cannot fork and do event processing in
+    the child if the event library was initialised before the fork (which
+    usually happens when the first AnyEvent watcher is created, or the
+    library is loaded).
     If you have to fork, you must either do so *before* creating your first
-    watcher OR you must not use AnyEvent at all in the child.
+    watcher OR you must not use AnyEvent at all in the child OR you must do
+    something completely out of the scope of AnyEvent.
+    The problem of doing event processing in the parent *and* the child is
+    much more complicated: even for backends that *are* fork-aware or
+    fork-safe, their behaviour is not usually what you want: fork clones all
+    watchers, that means all timers, I/O watchers etc. are active in both
+    parent and child, which is almost never what you want. USing "exec" to
+    start worker children from some kind of manage rprocess is usually
+    preferred, because it is much easier and cleaner, at the expense of
+    having to have another binary.
 SECURITY CONSIDERATIONS
     AnyEvent can be forced to load any event model via
     $ENV{PERL_ANYEVENT_MODEL}. While this cannot (to my knowledge) be used
     to execute arbitrary code or directly gain access, it can easily be used
     You can make AnyEvent completely ignore this variable by deleting it
     before the first watcher gets created, e.g. with a "BEGIN" block:
        BEGIN { delete $ENV{PERL_ANYEVENT_MODEL} }
-       use AnyEvent;
+   use AnyEvent;
     Similar considerations apply to $ENV{PERL_ANYEVENT_VERBOSE}, as that can
     be used to probe what backend is used and gain other information (which
     is probably even less useful to an attacker than PERL_ANYEVENT_MODEL),
     and $ENV{PERL_ANYEVENT_STRICT}.
     Event::Lib, Qt, POE.
     Implementations: AnyEvent::Impl::EV, AnyEvent::Impl::Event,
     AnyEvent::Impl::Glib, AnyEvent::Impl::Tk, AnyEvent::Impl::Perl,
     AnyEvent::Impl::EventLib, AnyEvent::Impl::Qt, AnyEvent::Impl::POE,
-    AnyEvent::Impl::IOAsync.
+    AnyEvent::Impl::IOAsync, Anyevent::Impl::Irssi.
     Non-blocking file handles, sockets, TCP clients and servers:
     AnyEvent::Handle, AnyEvent::Socket, AnyEvent::TLS.
     Asynchronous DNS: AnyEvent::DNS.

Diff Legend

-–
+Removed lines
-+
+Added lines
-<
+Changed lines
->
+Changed lines

Comparing AnyEvent/README (file contents): Revision 1.43 by root, Thu Jul 9 08:37:06 2009 UTC vs. Revision 1.61 by root, Wed Apr 28 14:15:55 2010 UTC

Diff Legend

Comparing AnyEvent/README (file contents):
Revision 1.43 by root, Thu Jul 9 08:37:06 2009 UTC vs.
Revision 1.61 by root, Wed Apr 28 14:15:55 2010 UTC