[ViewVC] Diff of: cvs/AnyEvent/README

Comparing AnyEvent/README (file contents):
Revision 1.33 by root, Thu Oct 30 03:43:13 2008 UTC vs.
Revision 1.40 by root, Tue Jun 23 23:37:32 2009 UTC

 NAME
     AnyEvent - provide framework for multiple event loops
-    EV, Event, Glib, Tk, Perl, Event::Lib, Qt, POE - various supported event
+    EV, Event, Glib, Tk, Perl, Event::Lib, Qt and POE are various supported
-    loops
+    event loops.
 SYNOPSIS
        use AnyEvent;
+       # file descriptor readable
-       my $w = AnyEvent->io (fh => $fh, poll => "r|w", cb => sub { ...  });
+       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 => ...
        print AnyEvent->now;  # prints current event loop time
        print AnyEvent->time; # think Time::HiRes::time or simply CORE::time.
+       # POSIX signal
        my $w = AnyEvent->signal (signal => "TERM", cb => sub { ... });
+       # child process exit
        my $w = AnyEvent->child (pid => $pid, cb => sub {
           my ($pid, $status) = @_;
           ...
        });
+       # called when event loop idle (if applicable)
+       my $w = AnyEvent->idle (cb => sub { ... });
        my $w = AnyEvent->condvar; # stores whether a condition was flagged
        $w->send; # wake up current and all future recv's
        $w->recv; # enters "main loop" till $condvar gets ->send
        # use a condvar in callback mode:
     These watchers are normal Perl objects with normal Perl lifetime. After
     creating a watcher it will immediately "watch" for events and invoke the
     callback when the event occurs (of course, only when the event model is
     in control).
+    Note that callbacks must not permanently change global variables
+    potentially in use by the event loop (such as $_ or $[) and that
+    callbacks must not "die". The former is good programming practise in
+    Perl and the latter stems from the fact that exception handling differs
+    widely between event loops.
     To disable the watcher you have to destroy it (e.g. by setting the
     variable you store it in to "undef" or otherwise deleting all references
     to it).
     All watchers are created by calling a method on the "AnyEvent" class.
   I/O WATCHERS
     You can create an I/O watcher by calling the "AnyEvent->io" method with
     the following mandatory key-value pairs as arguments:
-    "fh" the Perl *file handle* (*not* file descriptor) to watch for events
+    "fh" is the Perl *file handle* (*not* file descriptor) to watch for
-    (AnyEvent might or might not keep a reference to this file handle).
+    events (AnyEvent might or might not keep a reference to this file
+    handle). Note that only file handles pointing to things for which
+    non-blocking operation makes sense are allowed. This includes sockets,
+    most character devices, pipes, fifos and so on, but not for example
+    files or block devices.
     "poll" must be a string that is either "r" or "w", which creates a
-    watcher waiting for "r"eadable or "w"ritable events, respectively. "cb"
+    watcher waiting for "r"eadable or "w"ritable events, respectively.
-    is the callback to invoke each time the file handle becomes ready.
+    "cb" is the callback to invoke each time the file handle becomes ready.
     Although the callback might get passed parameters, their value and
     presence is undefined and you cannot rely on them. Portable AnyEvent
     callbacks cannot use arguments passed to I/O watcher callbacks.
         In either case, if you care (and in most cases, you don't), then you
         can get whatever behaviour you want with any event loop, by taking
         the difference between "AnyEvent->time" and "AnyEvent->now" into
         account.
+    AnyEvent->now_update
+        Some event loops (such as EV or AnyEvent::Impl::Perl) cache the
+        current time for each loop iteration (see the discussion of
+        AnyEvent->now, above).
+        When a callback runs for a long time (or when the process sleeps),
+        then this "current" time will differ substantially from the real
+        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".
+        Note that updating the time *might* cause some events to be handled.
   SIGNAL WATCHERS
     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.
     you "fork" the child (alternatively, you can call "AnyEvent::detect").
     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
+    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
+    to do, just before it would block the process to wait for new events.
+    Instead of blocking, the idle watcher is invoked.
+    Most event loops unfortunately do not really support idle watchers (only
+    EV, Event and Glib do it in a usable fashion) - for the rest, 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
+       my $idle_w;
+       my $io_w = AnyEvent->io (fh => \*STDIN, poll => 'r', cb => sub {
+          push @lines, scalar <STDIN>;
+          # start an idle watcher, if not already done
+          $idle_w ||= AnyEvent->idle (cb => sub {
+             # handle only one line, when there are lines left
+             if (my $line = shift @lines) {
+                print "handled when idle: $line";
+             } else {
+                # otherwise disable the idle watcher again
+                undef $idle_w;
+             }
+          });
+       });
   CONDITION VARIABLES
     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.
     "condvar->recv"), the Event and EV modules call "$Event/EV::DIED->()",
     Glib uses "install_exception_handler" and so on.
 ENVIRONMENT VARIABLES
     The following environment variables are used by this module or its
-    submodules:
+    submodules.
+    Note that AnyEvent will remove *all* environment variables starting with
+    "PERL_ANYEVENT_" from %ENV when it is loaded while taint mode is
+    enabled.
     "PERL_ANYEVENT_VERBOSE"
         By default, AnyEvent will be completely silent except in fatal
         conditions. You can set this environment variable to make AnyEvent
         more talkative.
         mentioned will be used, and preference will be given to protocols
         mentioned earlier in the list.
         This variable can effectively be used for denial-of-service attacks
         against local programs (e.g. when setuid), although the impact is
-        likely small, as the program has to handle connection errors
+        likely small, as the program has to handle conenction and other
-        already-
+        failures anyways.
         Examples: "PERL_ANYEVENT_PROTOCOLS=ipv4,ipv6" - prefer IPv4 over
         IPv6, but support both and try to use both.
         "PERL_ANYEVENT_PROTOCOLS=ipv4" - only support IPv4, never try to
         resolve or contact IPv6 addresses.
    Results
               name watchers bytes create invoke destroy comment
              EV/EV   400000   224   0.47   0.35    0.27 EV native interface
             EV/Any   100000   224   2.88   0.34    0.27 EV + AnyEvent watchers
         CoroEV/Any   100000   224   2.85   0.35    0.28 coroutines + Coro::Signal
-          Perl/Any   100000   452   4.14   0.75    0.99 pure perl implementation
+          Perl/Any   100000   452   4.13   0.73    0.95 pure perl implementation
        Event/Event    16000   517  32.20  31.80    0.81 Event native interface
          Event/Any    16000   590  35.85  31.55    1.06 Event + AnyEvent watchers
           Glib/Any    16000  1357 102.33  12.31   51.00 quadratic behaviour
             Tk/Any     2000  1860  27.20  66.31   14.00 SEGV with >> 2000 watchers
          POE/Event     2000  6328 109.99 751.67   14.02 via POE::Loop::Event
    Summary
     *   C-based event loops perform very well with small number of watchers,
         as the management overhead dominates.
+  THE IO::Lambda BENCHMARK
+    Recently I was told about the benchmark in the IO::Lambda manpage, which
+    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 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, 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
+       POE/select, optimized   0.404 sec
+       AnyEvent/select/nb      0.085 sec
+       AnyEvent/EV/nb          0.068 sec
+          +state machine       0.134 sec
+    The benchmark is also a bit unfair (my fault) - the IO::Lambda
+    benchmarks actually make blocking connects and use 100% blocking I/O,
+    defeating the purpose of an event-based solution. All of the newly
+    written AnyEvent benchmarks use 100% non-blocking connects (using
+    AnyEvent::Socket::tcp_connect and the asynchronous pure perl DNS
+    resolver), so AnyEvent is at a disadvantage here as non-blocking
+    connects generally require a lot more bookkeeping and event handling
+    than blocking connects (which involve a single syscall only).
+    The last AnyEvent benchmark additionally uses AnyEvent::Handle, which
+    offers similar expressive power as POE and IO::Lambda (using
+    conventional Perl syntax), which means both the echo server and the
+    client are 100% non-blocking w.r.t. I/O, further placing it at a
+    disadvantage.
+    As you can see, AnyEvent + EV 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, even
+    thought it does all of DNS, tcp-connect and socket I/O in a non-blocking
+    way.
+    The two AnyEvent benchmarks 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.
 SIGNALS
     AnyEvent currently installs handlers for these signals:
     SIGCHLD
         A handler for "SIGCHLD" is installed by AnyEvent's child watcher
     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_ANYEGENT_STRICT}.
+    and $ENV{PERL_ANYEVENT_STRICT}.
 BUGS
     Perl 5.8 has numerous memleaks that sometimes hit this module and are
     hard to work around. If you suffer from memleaks, first upgrade to Perl
     5.10 and check wether the leaks still show up. (Perl 5.10.0 has other
-    annoying mamleaks, such as leaking on "map" and "grep" but it is usually
+    annoying memleaks, such as leaking on "map" and "grep" but it is usually
     not as pronounced).
 SEE ALSO
     Utility functions: AnyEvent::Util.

Diff Legend

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

Comparing AnyEvent/README (file contents): Revision 1.33 by root, Thu Oct 30 03:43:13 2008 UTC vs. Revision 1.40 by root, Tue Jun 23 23:37:32 2009 UTC

Diff Legend

Comparing AnyEvent/README (file contents):
Revision 1.33 by root, Thu Oct 30 03:43:13 2008 UTC vs.
Revision 1.40 by root, Tue Jun 23 23:37:32 2009 UTC