[ViewVC] Diff of: cvs/AnyEvent/README

Comparing AnyEvent/README (file contents):
Revision 1.51 by root, Sun Aug 9 16:05:11 2009 UTC vs.
Revision 1.60 by root, Mon Apr 12 02:50:31 2010 UTC

     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 => ...
         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>);
     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.
        $done->recv;
   IDLE WATCHERS
        $w = AnyEvent->idle (cb => <callback>);
-    Sometimes there is a need to do something, but it is not so important to
+    Repeatedly invoke the callback after the process becomes idle, until
-    do it instantly, but only when there is nothing better to do. This
+    either the watcher is destroyed or new events have been detected.
-    "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
+    Idle watchers are useful when there is a need to do something, but it is
-    to do, just before it would block the process to wait for new events.
+    not so important (or wise) to do it instantly. The callback will be
-    Instead of blocking, the idle watcher is invoked.
+    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.
-    Most event loops unfortunately do not really support idle watchers (only
+    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
     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 callable directly.
        my $done = AnyEvent->condvar;
         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} = ...;
         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.
         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.
+    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
              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:
     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
     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 epxlains which additional modules will be used, and how
+    This section explains which additional modules will be used, and how
-    they affect AnyEvent's operetion.
+    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
         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).
+        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
         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
-        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. JSON is also written in pure-perl, but
-        advantage of the ultra-high-speed JSON::XS module when it is
+        can take advantage of the ultra-high-speed JSON::XS module when it
-        installed.
+        is installed.
-        In fact, AnyEvent::Handle will use JSON::XS by default if 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.
         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 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

Diff Legend

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

Comparing AnyEvent/README (file contents): Revision 1.51 by root, Sun Aug 9 16:05:11 2009 UTC vs. Revision 1.60 by root, Mon Apr 12 02:50:31 2010 UTC

Diff Legend

Comparing AnyEvent/README (file contents):
Revision 1.51 by root, Sun Aug 9 16:05:11 2009 UTC vs.
Revision 1.60 by root, Mon Apr 12 02:50:31 2010 UTC