--- AnyEvent/README 2009/08/01 09:14:54 1.50 +++ AnyEvent/README 2009/09/01 18:27:46 1.54 @@ -578,7 +578,7 @@ ); # this "blocks" (while handling events) till the callback - # calls -send $result_ready->recv; Example: wait for a timer, but take advantage of the fact that condition @@ -645,9 +645,10 @@ 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 - *supposed* to call "->send", but that is not required. If no - callback was set, "send" will be called without any arguments. + (last) callback passed to "begin" will be executed, passing the + condvar as first argument. That callback is *supposed* to call + "->send", but that is not required. If no group callback was set, + "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 @@ -685,7 +686,7 @@ 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; @@ -773,12 +774,11 @@ 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, - failing that, will fall back to its own pure-perl implementation, - which is available everywhere as it comes with AnyEvent itself. + use. If EV is not installed, then AnyEvent will fall back to its own + pure-perl implementation, which is available everywhere as it comes + 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. @@ -789,6 +789,7 @@ 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. @@ -1035,6 +1036,13 @@ 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 @@ -1222,16 +1230,9 @@ }, ); - my $time_watcher; # can only be used once - - sub new_timer { - $timer = AnyEvent->timer (after => 1, cb => sub { - warn "timeout\n"; # print 'timeout' about every second - &new_timer; # and restart the time - }); - } - - new_timer; # create first timer + my $time_watcher = AnyEvent->timer (after => 1, interval => 1, cb => sub { + warn "timeout\n"; # print 'timeout' at most every second + }); $cv->recv; # wait until user enters /^q/i @@ -1368,7 +1369,8 @@ 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 @@ -1397,18 +1399,18 @@ 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.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 - IOAsync/Any 16000 989 38.10 32.77 11.13 via IO::Async::Loop::IO_Poll - IOAsync/Any 16000 990 37.59 29.50 10.61 via IO::Async::Loop::Epoll - 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 - POE/Select 2000 6027 94.54 809.13 579.80 via POE::Loop::Select + EV/EV 100000 223 0.47 0.43 0.27 EV native interface + EV/Any 100000 223 0.48 0.42 0.26 EV + AnyEvent watchers + Coro::EV/Any 100000 223 0.47 0.42 0.26 coroutines + Coro::Signal + Perl/Any 100000 431 2.70 0.74 0.92 pure perl implementation + Event/Event 16000 516 31.16 31.84 0.82 Event native interface + Event/Any 16000 1203 42.61 34.79 1.80 Event + AnyEvent watchers + IOAsync/Any 16000 1911 41.92 27.45 16.81 via IO::Async::Loop::IO_Poll + IOAsync/Any 16000 1726 40.69 26.37 15.25 via IO::Async::Loop::Epoll + Glib/Any 16000 1118 89.00 12.57 51.17 quadratic behaviour + Tk/Any 2000 1346 20.96 10.75 8.00 SEGV with >> 2000 watchers + POE/Any 2000 6951 108.97 795.32 14.24 via POE::Loop::Event + 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 @@ -1429,9 +1431,10 @@ 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 - far less memory than any other event loop and is still faster than Event - natively. + 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 + any other event loop and is still faster than Event 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 @@ -1511,7 +1514,8 @@ 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" @@ -1527,13 +1531,13 @@ Results name sockets create request - EV 20000 69.01 11.16 - Perl 20000 73.32 35.87 - IOAsync 20000 157.00 98.14 epoll - IOAsync 20000 159.31 616.06 poll - Event 20000 212.62 257.32 - Glib 20000 651.16 1896.30 - POE 20000 349.67 12317.24 uses POE::Loop::Event + EV 20000 62.66 7.99 + Perl 20000 68.32 32.64 + IOAsync 20000 174.06 101.15 epoll + IOAsync 20000 174.67 610.84 poll + Event 20000 202.69 242.91 + Glib 20000 557.01 1689.52 + POE 20000 341.54 12086.32 uses POE::Loop::Event Discussion This benchmark *does* measure scalability and overall performance of the @@ -1656,13 +1660,13 @@ 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 - large margin, even though it does all of DNS, tcp-connect and socket I/O - in a non-blocking way. + slow :) AnyEvent::Handle abstraction beats both POE and IO::Lambda + higher level ("unoptimised") abstractions by a large margin, even though + 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: