[ViewVC] Diff of: cvs/AnyEvent/README

Comparing AnyEvent/README (file contents):
Revision 1.48 by root, Sun Jul 26 00:17:24 2009 UTC vs.
Revision 1.56 by root, Thu Nov 19 01:55:57 2009 UTC

 NAME
     AnyEvent - the DBI of event loop programming
-    EV, Event, Glib, Tk, Perl, Event::Lib, Irssi, IO::Async, Qt and POE are
+    EV, Event, Glib, Tk, Perl, Event::Lib, Irssi, rxvt-unicode, IO::Async,
-    various supported event loops/environments.
+    Qt and POE are various supported event loops/environments.
 SYNOPSIS
        use AnyEvent;
        # file descriptor readable
     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
        my $w = AnyEvent->signal (signal => "INT", cb => sub { exit 1 });
    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. AnyEvent will try to do it's best,
+    race-free signal handling in perl, requiring C libraries for this.
-    but in some cases, signals will be delayed. The maximum time a signal
+    AnyEvent will try to do it's best, which means in some cases, signals
-    might be delayed is specified in $AnyEvent::MAX_SIGNAL_LATENCY (default:
+    will be delayed. The maximum time a signal might be delayed is specified
-    10 seconds). This variable can be changed only before the first signal
+    in $AnyEvent::MAX_SIGNAL_LATENCY (default: 10 seconds). This variable
-    watcher is created, and should be left alone otherwise. Higher values
+    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.
-    saving. All these problems can be avoided by installing the optional
+    All these problems can be avoided by installing the optional
-    Async::Interrupt module. This will not work with inherently broken event
+    Async::Interrupt module, which works with most event loops. It will not
-    loops such as Event or Event::Lib (and not with POE currently, as POE
+    work with inherently broken event loops such as Event or Event::Lib (and
-    does it's own workaround with one-second latency). With those, you just
+    not with POE currently, as POE does it's own workaround with one-second
-    have to suffer the delays.
+    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 (one some backends,
     using 0 watches for any child process exit, on others this will croak).
     The watcher will be triggered only when the child process has finished
        # do something else, then wait for process exit
        $done->recv;
   IDLE WATCHERS
+       $w = AnyEvent->idle (cb => <callback>);
     Sometimes there is a need to do something, but it is not so important to
     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".
              }
           });
        });
   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 slightly different: it expects somebody else to run the
           after => 1,
           cb    => sub { $result_ready->send },
        );
        # this "blocks" (while handling events) till the callback
-       # calls -<send
+       # calls ->send
        $result_ready->recv;
     Example: wait for a timer, but take advantage of the fact that condition
     variables are also callable directly.
         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} = ...;
     $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.
     Event::ExecFlow
         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.
+    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
              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
     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
         "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
-        This module is required when you want to read or write JSON data via
+        One of these modules is required when you want to read or write JSON
-        AnyEvent::Handle. It is also written in pure-perl, but can take
+        data via AnyEvent::Handle. It is also written in pure-perl, but can
-        advantage of the ultra-high-speed JSON::XS module when it is
+        take advantage of the ultra-high-speed JSON::XS module when it is
         installed.
         In fact, AnyEvent::Handle will use JSON::XS by default if it is
         installed.

Diff Legend

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

Comparing AnyEvent/README (file contents): Revision 1.48 by root, Sun Jul 26 00:17:24 2009 UTC vs. Revision 1.56 by root, Thu Nov 19 01:55:57 2009 UTC

Diff Legend

Comparing AnyEvent/README (file contents):
Revision 1.48 by root, Sun Jul 26 00:17:24 2009 UTC vs.
Revision 1.56 by root, Thu Nov 19 01:55:57 2009 UTC