--- AnyEvent/README 2009/07/20 22:39:57 1.47 +++ AnyEvent/README 2009/11/19 01:55:57 1.56 @@ -1,8 +1,8 @@ NAME - AnyEvent - events independent of event loop implementation + AnyEvent - the DBI of event loop programming - EV, Event, Glib, Tk, Perl, Event::Lib, Qt and POE are various supported - event loops. + EV, Event, Glib, Tk, Perl, Event::Lib, Irssi, rxvt-unicode, IO::Async, + Qt and POE are various supported event loops/environments. SYNOPSIS use AnyEvent; @@ -45,7 +45,7 @@ channel, too. See the AnyEvent project page at the Schmorpforge Ta-Sa Software - Respository, at , for more info. + Repository, at , for more info. WHY YOU SHOULD USE THIS MODULE (OR NOT) Glib, POE, IO::Async, Event... CPAN offers event models by the dozen @@ -175,6 +175,12 @@ declared. I/O WATCHERS + $w = AnyEvent->io ( + fh => , + poll => <"r" or "w">, + cb => , + ); + You can create an I/O watcher by calling the "AnyEvent->io" method with the following mandatory key-value pairs as arguments: @@ -212,6 +218,14 @@ }); TIME WATCHERS + $w = AnyEvent->timer (after => , cb => ); + + $w = AnyEvent->timer ( + after => , + interval => , + cb => , + ); + You can create a time watcher by calling the "AnyEvent->timer" method with the following mandatory arguments: @@ -342,9 +356,19 @@ 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 => , cb => ); + 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. @@ -373,25 +397,32 @@ 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. AnyEvent will try to do it's best, - but in some cases, signals will be delayed. The maximum time a signal - might be delayed is specified in $AnyEvent::MAX_SIGNAL_LATENCY (default: - 10 seconds). This variable can be changed only before the first signal - watcher is created, and should be left alone otherwise. Higher values + race-free signal handling in perl, requiring C libraries for this. + AnyEvent will try to do it's best, which means in some cases, signals + will be delayed. The maximum time a signal might be delayed is specified + in $AnyEvent::MAX_SIGNAL_LATENCY (default: 10 seconds). This variable + can be changed only before the first signal watcher is created, and + should be left alone otherwise. This variable determines how often + AnyEvent polls for signals (in case a wake-up was missed). Higher values will cause fewer spurious wake-ups, which is better for power and CPU - saving. All these problems can be avoided by installing the optional - Async::Interrupt module. This will not work with inherently broken event - loops such as Event or Event::Lib (and not with POE currently, as POE - does it's own workaround with one-second latency). With those, you just - have to suffer the delays. + saving. + + All these problems can be avoided by installing the optional + Async::Interrupt module, which works with most event loops. It will not + work with inherently broken event loops such as Event or Event::Lib (and + not with POE currently, as POE does it's own workaround with one-second + latency). For those, you just have to suffer the delays. CHILD PROCESS WATCHERS + $w = AnyEvent->child (pid => , cb => ); + You can also watch on a child process exit and catch its exit status. - The child process is specified by the "pid" argument (if set to 0, it - watches for any child process exit). The watcher will triggered only - when the child process has finished and an exit status is available, not - on any trace events (stopped/continued). + The child process is specified by the "pid" argument (one some backends, + using 0 watches for any child process exit, on others this will croak). + The watcher will be triggered only when the child process has finished + and an exit status is available, not on any trace events + (stopped/continued). The callback will be called with the pid and exit status (as returned by waitpid), so unlike other watcher types, you *can* rely on child watcher @@ -440,6 +471,8 @@ $done->recv; IDLE WATCHERS + $w = AnyEvent->idle (cb => ); + 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 @@ -474,6 +507,11 @@ }); CONDITION VARIABLES + $cv = AnyEvent->condvar; + + $cv->send (); + my @res = $cv->recv; + 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. @@ -548,7 +586,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 @@ -615,9 +653,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 @@ -655,7 +694,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; @@ -732,22 +771,22 @@ 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 "send" or "croak" are called, with the only argument being the - condition variable itself. Calling "recv" inside the callback or at - any later time is guaranteed not to block. + The callback will be called when the condition becomes (or already + was) "true", i.e. when "send" or "croak" are called (or were + called), with the only argument being the condition variable itself. + Calling "recv" inside the callback or at any later time is + guaranteed not to block. SUPPORTED EVENT LOOPS/BACKENDS The available backend classes are (every class has its own manpage): 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. @@ -758,10 +797,12 @@ 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. AnyEvent::Impl::POE based on POE, very slow, some limitations. + AnyEvent::Impl::Irssi used when running within irssi. Backends with special needs. Qt requires the Qt::Application to be instantiated first, but will @@ -836,7 +877,24 @@ If called in scalar or list context, then it creates and returns an object that automatically removes the callback again when it is - destroyed. See Coro::BDB for a case where this is useful. + destroyed (or "undef" when the hook was immediately executed). See + AnyEvent::AIO for a case where this is useful. + + Example: Create a watcher for the IO::AIO module and store it in + $WATCHER. Only do so after the event loop is initialised, though. + + our WATCHER; + + my $guard = AnyEvent::post_detect { + $WATCHER = AnyEvent->io (fh => IO::AIO::poll_fileno, poll => 'r', cb => \&IO::AIO::poll_cb); + }; + + # the ||= is important in case post_detect immediately runs the block, + # as to not clobber the newly-created watcher. assigning both watcher and + # post_detect guard to the same variable has the advantage of users being + # able to just C if the watcher causes them grief. + + $WATCHER ||= $guard; @AnyEvent::post_detect If there are any code references in this array (you can "push" to it @@ -986,6 +1044,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 @@ -1173,16 +1238,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 @@ -1319,7 +1377,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 @@ -1348,18 +1407,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 @@ -1380,9 +1439,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 @@ -1462,7 +1522,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" @@ -1478,13 +1539,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 @@ -1607,13 +1668,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: @@ -1691,9 +1752,9 @@ 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 - AnyEvent::Handle. It is also written in pure-perl, but can take - advantage of the ultra-high-speed JSON::XS module when it is + One of these modules is required when you want to read or write JSON + data via AnyEvent::Handle. It is also written in pure-perl, but can + 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 @@ -1760,7 +1821,7 @@ Implementations: AnyEvent::Impl::EV, AnyEvent::Impl::Event, AnyEvent::Impl::Glib, AnyEvent::Impl::Tk, AnyEvent::Impl::Perl, AnyEvent::Impl::EventLib, AnyEvent::Impl::Qt, AnyEvent::Impl::POE, - AnyEvent::Impl::IOAsync. + AnyEvent::Impl::IOAsync, Anyevent::Impl::Irssi. Non-blocking file handles, sockets, TCP clients and servers: AnyEvent::Handle, AnyEvent::Socket, AnyEvent::TLS.