[ViewVC] Diff of: cvs/AnyEvent/lib/AnyEvent.pm

Comparing AnyEvent/lib/AnyEvent.pm (file contents):
Revision 1.95 by root, Sat Apr 26 11:06:45 2008 UTC vs.
Revision 1.109 by root, Sat May 10 00:45:18 2008 UTC

 =head1 NAME
 AnyEvent - provide framework for multiple event loops
-EV, Event, Coro::EV, Coro::Event, Glib, Tk, Perl, Event::Lib, Qt, POE - various supported event loops
+EV, Event, Glib, Tk, Perl, Event::Lib, Qt, POE - various supported event loops
 =head1 SYNOPSIS
    use AnyEvent;
    my $w = AnyEvent->timer (after => $seconds, cb => sub {
       ...
    });
    my $w = AnyEvent->condvar; # stores whether a condition was flagged
-   $w->wait; # enters "main loop" till $condvar gets ->broadcast
+   $w->wait; # enters "main loop" till $condvar gets ->send
-   $w->broadcast; # wake up current and all future wait's
+   $w->send; # wake up current and all future wait's
 =head1 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?
 Of course, if you want lots of policy (this can arguably be somewhat
 useful) and you want to force your users to use the one and only event
 model, you should I<not> use this module.
 =head1 DESCRIPTION
 L<AnyEvent> provides an identical interface to multiple event loops. This
 allows module authors to utilise an event loop without forcing module
 users to use the same event loop (as only a single event loop can coexist
 The interface itself is vaguely similar, but not identical to the L<Event>
 module.
 During the first call of any watcher-creation method, the module tries
 to detect the currently loaded event loop by probing whether one of the
-following modules is already loaded: L<Coro::EV>, L<Coro::Event>, L<EV>,
+following modules is already loaded: L<EV>,
 L<Event>, L<Glib>, L<AnyEvent::Impl::Perl>, L<Tk>, L<Event::Lib>, L<Qt>,
 L<POE>. The first one found is used. If none are found, the module tries
 to load these modules (excluding Tk, Event::Lib, Qt and POE as the pure perl
 adaptor should always succeed) in the order given. The first one that can
 be successfully loaded will be used. If, after this, still none could be
   my $w = AnyEvent->child (
      pid => $pid,
      cb  => sub {
         my ($pid, $status) = @_;
         warn "pid $pid exited with status $status";
-        $done->broadcast;
+        $done->send;
      },
   );
   # do something else, then wait for process exit
   $done->wait;
 =head2 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.
+AnyEvent is different, it expects somebody else to run the 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.
-Condition variables can be created by calling the C<< AnyEvent->condvar >>
+Condition variables can be created by calling the C<< AnyEvent->condvar
-method without any arguments.
+>> method, usually without arguments. The only argument pair allowed is
+C<cb>, which specifies a callback to be called when the condition variable
+becomes true.
-A condition variable waits for a condition - precisely that the C<<
+After creation, the conditon variable is "false" until it becomes "true"
-->broadcast >> method has been called.
+by calling the C<send> method.
-They are very useful to signal that a condition has been fulfilled, for
+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 outstandign events have been processed. And yet
+another way to call them is transations - each condition variable can be
+used to represent a transaction, which finishes at some point and delivers
+a result.
+Condition variables are very useful to signal that something has finished,
-example, if you write a module that does asynchronous http requests,
+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.
+availability of results. The user can either act when the callback is
+called or can synchronously C<< ->wait >> for the results.
-You can also use condition variables to block your main program until
+You can also use them to simulate traditional event loops - for example,
-an event occurs - for example, you could C<< ->wait >> in your main
+you can block your main program until an event occurs - for example, you
-program until the user clicks the Quit button in your app, which would C<<
+could C<< ->wait >> in your main program until the user clicks the Quit
-->broadcast >> the "quit" event.
+button of your app, which would C<< ->send >> the "quit" event.
 Note that condition variables recurse into the event loop - if you have
-two pirces of code that call C<< ->wait >> in a round-robbin fashion, you
+two pieces of code that call C<< ->wait >> in a round-robbin fashion, you
 lose. Therefore, condition variables are good to export to your caller, but
 you should avoid making a blocking wait yourself, at least in callbacks,
 as this asks for trouble.
-This object has two methods:
+Condition variables are represented by hash refs in perl, and the keys
+used by AnyEvent itself are all named C<_ae_XXX> to make subclassing
+easy (it is often useful to build your own transaction class on top of
+AnyEvent). To subclass, use C<AnyEvent::CondVar> as base class and call
+it's C<new> method in your own C<new> method.
+There are two "sides" to a condition variable - the "producer side" which
+eventually calls C<< -> send >>, and the "consumer side", which waits
+for the send to occur.
+Example:
+   # wait till the result is ready
+   my $result_ready = AnyEvent->condvar;
+   # do something such as adding a timer
+   # or socket watcher the calls $result_ready->send
+   # when the "result" is ready.
+   # in this case, we simply use a timer:
+   my $w = AnyEvent->timer (
+      after => 1,
+      cb    => sub { $result_ready->send },
+   );
+   # this "blocks" (while handling events) till the callback
+   # calls send
+   $result_ready->wait;
+=head3 METHODS FOR PRODUCERS
+These methods should only be used by the producing side, i.e. the
+code/module that eventually sends the signal. Note that it is also
+the producer side which creates the condvar in most cases, but it isn't
+uncommon for the consumer to create it as well.
 =over 4
+=item $cv->send (...)
+Flag the condition as ready - a running C<< ->wait >> and all further
+calls to C<wait> will (eventually) return after this method has been
+called. If nobody is waiting the send will be remembered.
+If a callback has been set on the condition variable, it is called
+immediately from within send.
+Any arguments passed to the C<send> call will be returned by all
+future C<< ->wait >> calls.
+=item $cv->croak ($error)
+Similar to send, but causes all call's wait C<< ->wait >> to invoke
+C<Carp::croak> with the given error message/object/scalar.
+This can be used to signal any errors to the condition variable
+user/consumer.
+=item $cv->begin ([group callback])
+=item $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 C<< ->begin >> will increment a counter, and every call to
+C<< ->end >> will decrement it.  If the counter reaches C<0> in C<< ->end
+>>, the (last) callback passed to C<begin> will be executed. That callback
+is I<supposed> to call C<< ->send >>, but that is not required. If no
+callback was set, C<send> will be called without any arguments.
+Let's clarify this with the ping example:
+   my $cv = AnyEvent->condvar;
+   my %result;
+   $cv->begin (sub { $cv->send (\%result) });
+   for my $host (@list_of_hosts) {
+      $cv->begin;
+      ping_host_then_call_callback $host, sub {
+         $result{$host} = ...;
+         $cv->end;
+      };
+   }
+   $cv->end;
+This code fragment supposedly pings a number of hosts and calls
+C<send> after results for all then have have been gathered - in any
+order. To achieve this, the code issues a call to C<begin> when it starts
+each ping request and calls C<end> when it has received some result for
+it. Since C<begin> and C<end> only maintain a counter, the order in which
+results arrive is not relevant.
+There is an additional bracketing call to C<begin> and C<end> outside the
+loop, which serves two important purposes: first, it sets the callback
+to be called once the counter reaches C<0>, and second, it ensures that
+C<send> is called even when C<no> hosts are being pinged (the loop
+doesn't execute once).
+This is the general pattern when you "fan out" into multiple subrequests:
+use an outer C<begin>/C<end> pair to set the callback and ensure C<end>
+is called at least once, and then, for each subrequest you start, call
+C<begin> and for eahc subrequest you finish, call C<end>.
+=back
+=head3 METHODS FOR CONSUMERS
+These methods should only be used by the consuming side, i.e. the
+code awaits the condition.
+=over 4
 =item $cv->wait
-Wait (blocking if necessary) until the C<< ->broadcast >> method has been
+Wait (blocking if necessary) until the C<< ->send >> or C<< ->croak
-called on c<$cv>, while servicing other watchers normally.
+>> methods have been called on c<$cv>, while servicing other watchers
+normally.
-You can only wait once on a condition - additional calls will return
+You can only wait once on a condition - additional calls are valid but
-immediately.
+will return immediately.
+If an error condition has been set by calling C<< ->croak >>, then this
+function will call C<croak>.
+In list context, all parameters passed to C<send> will be returned,
+in scalar context only the first one will be returned.
 Not all event models support a blocking wait - some die in that case
 (programs might want to do that to stay interactive), so I<if you are
 using this from a module, never require a blocking wait>, but let the
 caller decide whether the call will block or not (for example, by coupling
 while still suppporting blocking waits if the caller so desires).
 Another reason I<never> to C<< ->wait >> in a module is that you cannot
 sensibly have two C<< ->wait >>'s in parallel, as that would require
 multiple interpreters or coroutines/threads, none of which C<AnyEvent>
-can supply (the coroutine-aware backends L<AnyEvent::Impl::CoroEV> and
+can supply.
-L<AnyEvent::Impl::CoroEvent> explicitly support concurrent C<< ->wait >>'s
-from different coroutines, however).
-=item $cv->broadcast
+The L<Coro> module, however, I<can> and I<does> supply coroutines and, in
+fact, L<Coro::AnyEvent> replaces AnyEvent's condvars by coroutine-safe
+versions and also integrates coroutines into AnyEvent, making blocking
+C<< ->wait >> calls perfectly safe as long as they are done from another
+coroutine (one that doesn't run the event loop).
-Flag the condition as ready - a running C<< ->wait >> and all further
+You can ensure that C<< -wait >> never blocks by setting a callback and
-calls to C<wait> will (eventually) return after this method has been
+only calling C<< ->wait >> from within that callback (or at a later
-called. If nobody is waiting the broadcast will be remembered..
+time). This will work even when the event loop does not support blocking
+waits otherwise.
+=item $bool = $cv->ready
+Returns true when the condition is "true", i.e. whether C<send> or
+C<croak> have been called.
+=item $cb = $cv->cb ([new callback])
+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. when
+C<send> or C<croak> are called. Calling C<wait> inside the callback
+or at any later time is guaranteed not to block.
 =back
-Example:
-   # wait till the result is ready
-   my $result_ready = AnyEvent->condvar;
-   # do something such as adding a timer
-   # or socket watcher the calls $result_ready->broadcast
-   # when the "result" is ready.
-   # in this case, we simply use a timer:
-   my $w = AnyEvent->timer (
-      after => 1,
-      cb    => sub { $result_ready->broadcast },
-   );
-   # this "blocks" (while handling events) till the watcher
-   # calls broadcast
-   $result_ready->wait;
 =head1 GLOBAL VARIABLES AND FUNCTIONS
 =over 4
 C<AnyEvent::Impl:xxx> modules, but can be any other class in the case
 AnyEvent has been extended at runtime (e.g. in I<rxvt-unicode>).
 The known classes so far are:
-   AnyEvent::Impl::CoroEV    based on Coro::EV, best choice.
-   AnyEvent::Impl::CoroEvent based on Coro::Event, second best choice.
    AnyEvent::Impl::EV        based on EV (an interface to libev, best choice).
    AnyEvent::Impl::Event     based on Event, second best choice.
+   AnyEvent::Impl::Perl      pure-perl implementation, fast and portable.
    AnyEvent::Impl::Glib      based on Glib, third-best choice.
-   AnyEvent::Impl::Perl      pure-perl implementation, inefficient but portable.
    AnyEvent::Impl::Tk        based on Tk, very bad choice.
    AnyEvent::Impl::Qt        based on Qt, cannot be autoprobed (see its docs).
    AnyEvent::Impl::EventLib  based on Event::Lib, leaks memory and worse.
    AnyEvent::Impl::POE       based on POE, not generic enough for full support.
 Returns C<$AnyEvent::MODEL>, forcing autodetection of the event model
 if necessary. You should only call this function right before you would
 have created an AnyEvent watcher anyway, that is, as late as possible at
 runtime.
+=item AnyEvent::on_detect { BLOCK }
+Arranges for the code block to be executed as soon as the event model is
+autodetected (or immediately if this has already happened).
+=item @AnyEvent::on_detect
+If there are any code references in this array (you can C<push> to it
+before or after loading AnyEvent), then they will called directly after
+the event loop has been chosen.
+You should check C<$AnyEvent::MODEL> before adding to this array, though:
+if it contains a true value then the event loop has already been detected,
+and the array will be ignored.
+Best use C<AnyEvent::on_detect { BLOCK }> instead.
 =back
 =head1 WHAT TO DO IN A MODULE
 As a module author, you should C<use AnyEvent> and call AnyEvent methods
 decide which event module to use as soon as the first method is called, so
 by calling AnyEvent in your module body you force the user of your module
 to load the event module first.
 Never call C<< ->wait >> on a condition variable unless you I<know> that
-the C<< ->broadcast >> method has been called on it already. This is
+the C<< ->send >> method has been called on it already. This is
 because it will stall the whole program, and the whole point of using
 events is to stay interactive.
 It is fine, however, to call C<< ->wait >> when the user of your module
 requests it (i.e. if you create a http request object ad have a method
 You can chose to use a rather inefficient pure-perl implementation by
 loading the C<AnyEvent::Impl::Perl> module, which gives you similar
 behaviour everywhere, but letting AnyEvent chose is generally better.
+=head1 OTHER MODULES
+The following is a non-exhaustive list of additional modules that use
+AnyEvent and can therefore be mixed easily with other AnyEvent modules
+in the same program. Some of the modules come with AnyEvent, some are
+available via CPAN.
+=over 4
+=item L<AnyEvent::Util>
+Contains various utility functions that replace often-used but blocking
+functions such as C<inet_aton> by event-/callback-based versions.
+=item L<AnyEvent::Handle>
+Provide read and write buffers and manages watchers for reads and writes.
+=item L<AnyEvent::Socket>
+Provides a means to do non-blocking connects, accepts etc.
+=item L<AnyEvent::HTTPD>
+Provides a simple web application server framework.
+=item L<AnyEvent::DNS>
+Provides asynchronous DNS resolver capabilities, beyond what
+L<AnyEvent::Util> offers.
+=item L<AnyEvent::FastPing>
+The fastest ping in the west.
+=item L<Net::IRC3>
+AnyEvent based IRC client module family.
+=item L<Net::XMPP2>
+AnyEvent based XMPP (Jabber protocol) module family.
+=item L<Net::FCP>
+AnyEvent-based implementation of the Freenet Client Protocol, birthplace
+of AnyEvent.
+=item L<Event::ExecFlow>
+High level API for event-based execution flow control.
+=item L<Coro>
+Has special support for AnyEvent via L<Coro::AnyEvent>.
+=item L<IO::Lambda>
+The lambda approach to I/O - don't ask, look there. Can use AnyEvent.
+=item L<IO::AIO>
+Truly asynchronous I/O, should be in the toolbox of every event
+programmer. Can be trivially made to use AnyEvent.
+=item L<BDB>
+Truly asynchronous Berkeley DB access. Can be trivially made to use
+AnyEvent.
+=back
 =cut
 package AnyEvent;
 no warnings;
 use strict;
 use Carp;
-our $VERSION = '3.3';
+our $VERSION = '3.4';
 our $MODEL;
 our $AUTOLOAD;
 our @ISA;
 our $verbose = $ENV{PERL_ANYEVENT_VERBOSE}*1;
 our @REGISTRY;
 my @models = (
-   [Coro::EV::             => AnyEvent::Impl::CoroEV::],
-   [Coro::Event::          => AnyEvent::Impl::CoroEvent::],
    [EV::                   => AnyEvent::Impl::EV::],
    [Event::                => AnyEvent::Impl::Event::],
-   [Glib::                 => AnyEvent::Impl::Glib::],
    [Tk::                   => AnyEvent::Impl::Tk::],
    [Wx::                   => AnyEvent::Impl::POE::],
    [Prima::                => AnyEvent::Impl::POE::],
    [AnyEvent::Impl::Perl:: => AnyEvent::Impl::Perl::],
    # everything below here will not be autoprobed as the pureperl backend should work everywhere
+   [Glib::                 => AnyEvent::Impl::Glib::],
    [Event::Lib::           => AnyEvent::Impl::EventLib::], # too buggy
    [Qt::                   => AnyEvent::Impl::Qt::],       # requires special main program
    [POE::Kernel::          => AnyEvent::Impl::POE::],      # lasciate ogni speranza
 );
-our %method = map +($_ => 1), qw(io timer signal child condvar broadcast wait one_event DESTROY);
+our %method = map +($_ => 1), qw(io timer signal child condvar one_event DESTROY);
+our @on_detect;
+sub on_detect(&) {
+   if ($MODEL) {
+      $_[0]->();
+   } else {
+      push @on_detect, $_[0];
+   }
+}
 sub detect() {
    unless ($MODEL) {
       no strict 'refs';
                   last;
                }
             }
             $MODEL
-              or die "No event module selected for AnyEvent and autodetect failed. Install any one of these modules: EV (or Coro+EV), Event (or Coro+Event) or Glib.";
+              or die "No event module selected for AnyEvent and autodetect failed. Install any one of these modules: EV, Event or Glib.";
          }
       }
       unshift @ISA, $MODEL;
       push @{"$MODEL\::ISA"}, "AnyEvent::Base";
+      (shift @on_detect)->() while @on_detect;
    }
    $MODEL
 }
          EV/EV   400000   244   0.56   0.46    0.31 EV native interface
         EV/Any   100000   244   2.50   0.46    0.29 EV + AnyEvent watchers
     CoroEV/Any   100000   244   2.49   0.44    0.29 coroutines + Coro::Signal
       Perl/Any   100000   513   4.92   0.87    1.12 pure perl implementation
    Event/Event    16000   516  31.88  31.30    0.85 Event native interface
-     Event/Any    16000   936  39.17  33.63    1.43 Event + AnyEvent watchers
+     Event/Any    16000   590  35.75  31.42    1.08 Event + AnyEvent watchers
       Glib/Any    16000  1357  98.22  12.41   54.00 quadratic behaviour
         Tk/Any     2000  1860  26.97  67.98   14.00 SEGV with >> 2000 watchers
      POE/Event     2000  6644 108.64 736.02   14.73 via POE::Loop::Event
     POE/Select     2000  6343  94.13 809.12  565.96 via POE::Loop::Select
 Also, note that the number of watchers usually has a nonlinear effect on
 overall speed, that is, creating twice as many watchers doesn't take twice
 the time - usually it takes longer. This puts event loops tested with a
 higher number of watchers at a disadvantage.
+To put the range of results into perspective, consider that on the
+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.
 C<EV> is the sole leader regarding speed and memory use, which are both
 maximal/minimal, respectively. Even when going through AnyEvent, it uses
 far less memory than any other event loop and is still faster than Event
 natively.
 file descriptor is dup()ed for each watcher. This shows that the dup()
 employed by some adaptors is not a big performance issue (it does incur a
 hidden memory cost inside the kernel which is not reflected in the figures
 above).
-C<POE>, regardless of underlying event loop (whether using its pure
+C<POE>, regardless of underlying event loop (whether using its pure perl
-perl select-based backend or the Event module, the POE-EV backend
+select-based backend or the Event module, the POE-EV backend couldn't
-couldn't be tested because it wasn't working) shows abysmal performance
+be tested because it wasn't working) shows abysmal performance and
-and memory usage: Watchers use almost 30 times as much memory as
+memory usage with AnyEvent: Watchers use almost 30 times as much memory
-EV watchers, and 10 times as much memory as Event (the high memory
+as EV watchers, and 10 times as much memory as Event (the high memory
 requirements are caused by requiring a session for each watcher). Watcher
 invocation speed is almost 900 times slower than with AnyEvent's pure perl
+implementation.
-implementation. The design of the POE adaptor class in AnyEvent can not
+The design of the POE adaptor class in AnyEvent can not really account
-really account for this, as session creation overhead is small compared
+for the performance issues, though, as session creation overhead is
-to execution of the state machine, which is coded pretty optimally within
+small compared to execution of the state machine, which is coded pretty
-L<AnyEvent::Impl::POE>. POE simply seems to be abysmally slow.
+optimally within L<AnyEvent::Impl::POE> (and while everybody agrees that
+using multiple sessions is not a good approach, especially regarding
+memory usage, even the author of POE could not come up with a faster
+design).
 =head3 Summary
 =over 4
 =head3 Results
     name sockets create  request
       EV   20000  69.01    11.16
-    Perl   20000  75.28   112.76
+    Perl   20000  73.32    35.87
    Event   20000 212.62   257.32
     Glib   20000 651.16  1896.30
      POE   20000 349.67 12317.24 uses POE::Loop::Event
 =head3 Discussion
 =head3 Summary
 =over 4
-=item * The pure perl implementation performs extremely well, considering
+=item * The pure perl implementation performs extremely well.
-that it uses select.
 =item * Avoid Glib or POE in large projects where performance matters.
 =back
 =head3 Results
     name sockets create request
       EV      16  20.00    6.54
+    Perl      16  25.75   12.62
    Event      16  81.27   35.86
     Glib      16  32.63   15.48
-    Perl      16  24.62  162.37
      POE      16 261.87  276.28 uses POE::Loop::Event
 =head3 Discussion
 The benchmark tries to test the performance of a typical small
 server. While knowing how various event loops perform is interesting, keep
 in mind that their overhead in this case is usually not as important, due
-to the small absolute number of watchers.
+to the small absolute number of watchers (that is, you need efficiency and
+speed most when you have lots of watchers, not when you only have a few of
+them).
 EV is again fastest.
-The C-based event loops Event and Glib come in second this time, as the
+Perl again comes second. It is noticably faster than the C-based event
-overhead of running an iteration is much smaller in C than in Perl (little
+loops Event and Glib, although the difference is too small to really
-code to execute in the inner loop, and perl's function calling overhead is
+matter.
-high, and updating all the data structures is costly).
-The pure perl event loop is much slower, but still competitive.
-POE also performs much better in this case, but is is stillf ar behind the
+POE also performs much better in this case, but is is still far behind the
 others.
 =head3 Summary
 =over 4
 =head1 FORK
 Most event libraries are not fork-safe. The ones who are usually are
-because they are so inefficient. Only L<EV> is fully fork-aware.
+because they rely on inefficient but fork-safe C<select> or C<poll>
+calls. Only L<EV> is fully fork-aware.
 If you have to fork, you must either do so I<before> creating your first
 watcher OR you must not use AnyEvent at all in the child.
   BEGIN { delete $ENV{PERL_ANYEVENT_MODEL} }
   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).
 =head1 SEE ALSO
-Event modules: L<Coro::EV>, L<EV>, L<EV::Glib>, L<Glib::EV>,
+Event modules: L<EV>, L<EV::Glib>, L<Glib::EV>, L<Event>, L<Glib::Event>,
-L<Coro::Event>, L<Event>, L<Glib::Event>, L<Glib>, L<Coro>, L<Tk>,
-L<Event::Lib>, L<Qt>, L<POE>.
+L<Glib>, L<Tk>, L<Event::Lib>, L<Qt>, L<POE>.
-Implementations: L<AnyEvent::Impl::CoroEV>, L<AnyEvent::Impl::EV>,
+Implementations: L<AnyEvent::Impl::EV>, L<AnyEvent::Impl::Event>,
-L<AnyEvent::Impl::CoroEvent>, L<AnyEvent::Impl::Event>, L<AnyEvent::Impl::Glib>,
+L<AnyEvent::Impl::Glib>, L<AnyEvent::Impl::Tk>, L<AnyEvent::Impl::Perl>,
-L<AnyEvent::Impl::Tk>, L<AnyEvent::Impl::Perl>, L<AnyEvent::Impl::EventLib>,
+L<AnyEvent::Impl::EventLib>, L<AnyEvent::Impl::Qt>,
-L<AnyEvent::Impl::Qt>, L<AnyEvent::Impl::POE>.
+L<AnyEvent::Impl::POE>.
+Coroutine support: L<Coro>, L<Coro::AnyEvent>, L<Coro::EV>, L<Coro::Event>,
 Nontrivial usage examples: L<Net::FCP>, L<Net::XMPP2>.
 =head1 AUTHOR

Diff Legend

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

Comparing AnyEvent/lib/AnyEvent.pm (file contents): Revision 1.95 by root, Sat Apr 26 11:06:45 2008 UTC vs. Revision 1.109 by root, Sat May 10 00:45:18 2008 UTC

Diff Legend

Comparing AnyEvent/lib/AnyEvent.pm (file contents):
Revision 1.95 by root, Sat Apr 26 11:06:45 2008 UTC vs.
Revision 1.109 by root, Sat May 10 00:45:18 2008 UTC