[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.56 by root, Thu Nov 19 01:55:57 2009 UTC

         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".
+        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>);
           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} = ...;
              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
     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.51 by root, Sun Aug 9 16:05:11 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.51 by root, Sun Aug 9 16:05:11 2009 UTC vs.
Revision 1.56 by root, Thu Nov 19 01:55:57 2009 UTC