--- AnyEvent/README 2009/06/23 23:37:32 1.40 +++ AnyEvent/README 2009/07/20 22:39:57 1.47 @@ -1,5 +1,5 @@ NAME - AnyEvent - provide framework for multiple event loops + AnyEvent - events independent of event loop implementation EV, Event, Glib, Tk, Perl, Event::Lib, Qt and POE are various supported event loops. @@ -40,6 +40,13 @@ tutorial or some gentle introduction, have a look at the AnyEvent::Intro manpage. +SUPPORT + There is a mailinglist for discussing all things AnyEvent, and an IRC + channel, too. + + See the AnyEvent project page at the Schmorpforge Ta-Sa Software + Respository, at , for more info. + 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? @@ -171,7 +178,7 @@ You can create an I/O watcher by calling the "AnyEvent->io" method with the following mandatory key-value pairs as arguments: - "fh" is the Perl *file handle* (*not* file descriptor) to watch for + "fh" is the Perl *file handle* (or a naked file descriptor) to watch for events (AnyEvent might or might not keep a reference to this file handle). Note that only file handles pointing to things for which non-blocking operation makes sense are allowed. This includes sockets, @@ -352,15 +359,32 @@ process, but it is guaranteed not to interrupt any other callbacks. The main advantage of using these watchers is that you can share a - signal between multiple watchers. + signal between multiple watchers, and AnyEvent will ensure that signals + will not interrupt your program at bad times. - This watcher might use %SIG, so programs overwriting those signals - directly will likely not work correctly. + This watcher might use %SIG (depending on the event loop used), so + programs overwriting those signals directly will likely not work + correctly. Example: exit on SIGINT my $w = AnyEvent->signal (signal => "INT", cb => sub { exit 1 }); + 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 + 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. + CHILD PROCESS WATCHERS You can also watch on a child process exit and catch its exit status. @@ -382,15 +406,21 @@ them *after* the child process was created, and this means the process could have exited already (and no SIGCHLD will be sent anymore). - Not all event models handle this correctly (POE doesn't), but even for - event models that *do* handle this correctly, they usually need to be - loaded before the process exits (i.e. before you fork in the first - place). + Not all event models handle this correctly (neither POE nor IO::Async + do, see their AnyEvent::Impl manpages for details), but even for event + models that *do* handle this correctly, they usually need to be loaded + before the process exits (i.e. before you fork in the first place). + AnyEvent's pure perl event loop handles all cases correctly regardless + of when you start the watcher. This means you cannot create a child watcher as the very first thing in an AnyEvent program, you *have* to create at least one watcher before you "fork" the child (alternatively, you can call "AnyEvent::detect"). + As most event loops do not support waiting for child events, they will + be emulated by AnyEvent in most cases, in which the latency and race + problems mentioned in the description of signal watchers apply. + Example: fork a process and wait for it my $done = AnyEvent->condvar; @@ -448,15 +478,17 @@ 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). + AnyEvent is slightly 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. + Now is probably a good time to look at the examples further below. + Condition variables can be created by calling the "AnyEvent->condvar" method, usually without arguments. The only argument pair allowed is - "cb", which specifies a callback to be called when the condition variable becomes true, with the condition variable as the first argument (but not the results). @@ -471,7 +503,8 @@ in time where multiple outstanding events have been processed. And yet another way to call them is transactions - each condition variable can be used to represent a transaction, which finishes at some point and - delivers a result. + delivers a result. And yet some people know them as "futures" - a + promise to compute/deliver something that you can wait for. Condition variables are very useful to signal that something has finished, for example, if you write a module that does asynchronous http @@ -515,11 +548,11 @@ ); # this "blocks" (while handling events) till the callback - # calls send + # calls -recv; Example: wait for a timer, but take advantage of the fact that condition - variables are also code references. + variables are also callable directly. my $done = AnyEvent->condvar; my $delay = AnyEvent->timer (after => 5, cb => $done); @@ -535,7 +568,7 @@ my @info = $couchdb->info->recv; - And this is how you would just ste a callback to be called whenever the + And this is how you would just set a callback to be called whenever the results are available: $couchdb->info->cb (sub { @@ -560,25 +593,22 @@ future "->recv" calls. Condition variables are overloaded so one can call them directly (as - a code reference). Calling them directly is the same as calling - "send". Note, however, that many C-based event loops do not handle - overloading, so as tempting as it may be, passing a condition - variable instead of a callback does not work. Both the pure perl and - EV loops support overloading, however, as well as all functions that - use perl to invoke a callback (as in AnyEvent::Socket and - AnyEvent::DNS for example). + if they were a code reference). Calling them directly is the same as + calling "send". $cv->croak ($error) Similar to send, but causes all call's to "->recv" to invoke "Carp::croak" with the given error message/object/scalar. This can be used to signal any errors to the condition variable - user/consumer. + user/consumer. Doing it this way instead of calling "croak" directly + delays the error detetcion, but has the overwhelmign advantage that + it diagnoses the error at the place where the result is expected, + and not deep in some event clalback without connection to the actual + code causing the problem. $cv->begin ([group callback]) $cv->end - These two methods are EXPERIMENTAL and MIGHT CHANGE. - 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. @@ -589,7 +619,38 @@ *supposed* to call "->send", but that is not required. If no callback was set, "send" will be called without any arguments. - Let's clarify this with the ping example: + 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). + + Let's start with a simple example: you have two I/O watchers (for + example, STDOUT and STDERR for a program), and you want to wait for + both streams to close before activating a condvar: + + my $cv = AnyEvent->condvar; + + $cv->begin; # first watcher + my $w1 = AnyEvent->io (fh => $fh1, cb => sub { + defined sysread $fh1, my $buf, 4096 + or $cv->end; + }); + + $cv->begin; # second watcher + my $w2 = AnyEvent->io (fh => $fh2, cb => sub { + defined sysread $fh2, my $buf, 4096 + or $cv->end; + }); + + $cv->recv; + + This works because for every event source (EOF on file handle), + there is one call to "begin", so the condvar waits for all calls to + "end" before sending. + + The ping example mentioned above is slightly more complicated, as + the there are results to be passwd back, and the number of tasks + that are begung can potentially be zero: my $cv = AnyEvent->condvar; @@ -619,11 +680,11 @@ ensures that "send" is called even when "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 "begin"/"end" pair to set the callback and - ensure "end" is called at least once, and then, for each subrequest - you start, call "begin" and for each subrequest you finish, call - "end". + This is the general pattern when you "fan out" into multiple (but + potentially none) subrequests: use an outer "begin"/"end" pair to + set the callback and ensure "end" is called at least once, and then, + for each subrequest you start, call "begin" and for each subrequest + you finish, call "end". METHODS FOR CONSUMERS These methods should only be used by the consuming side, i.e. the code @@ -642,25 +703,21 @@ In list context, all parameters passed to "send" will be returned, in scalar context only the first one will be returned. + Note that doing a blocking wait in a callback is not supported by + any event loop, that is, recursive invocation of a blocking "->recv" + is not allowed, and the "recv" call will "croak" if such a condition + is detected. This condition can be slightly loosened by using + Coro::AnyEvent, which allows you to do a blocking "->recv" from any + thread that doesn't run the event loop itself. + Not all event models support a blocking wait - some die in that case (programs might want to do that to stay interactive), so *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 condition variables with some kind of request results - and supporting callbacks so the caller knows that getting the result - will not block, while still supporting blocking waits if the caller - so desires). - - Another reason *never* to "->recv" in a module is that you cannot - sensibly have two "->recv"'s in parallel, as that would require - multiple interpreters or coroutines/threads, none of which - "AnyEvent" can supply. - - The Coro module, however, *can* and *does* supply coroutines and, in - fact, Coro::AnyEvent replaces AnyEvent's condvars by coroutine-safe - versions and also integrates coroutines into AnyEvent, making - blocking "->recv" calls perfectly safe as long as they are done from - another coroutine (one that doesn't run the event loop). + using this from a module, never require a blocking wait*. Instead, + let the caller decide whether the call will block or not (for + example, by coupling condition variables with some kind of request + results and supporting callbacks so the caller knows that getting + the result will not block, while still supporting blocking waits if + the caller so desires). You can ensure that "-recv" never blocks by setting a callback and only calling "->recv" from within that callback (or at a later @@ -680,45 +737,103 @@ condition variable itself. Calling "recv" inside the callback or at any later time is guaranteed not to block. -GLOBAL VARIABLES AND FUNCTIONS - $AnyEvent::MODEL - Contains "undef" until the first watcher is being created. Then it - contains the event model that is being used, which is the name of - the Perl class implementing the model. This class is usually one of - the "AnyEvent::Impl:xxx" modules, but can be any other class in the - case AnyEvent has been extended at runtime (e.g. in *rxvt-unicode*). +SUPPORTED EVENT LOOPS/BACKENDS + The available backend classes are (every class has its own manpage): - The known classes so far are: + 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. - AnyEvent::Impl::EV based on EV (an interface to libev, best choice). - AnyEvent::Impl::Event based on Event, second best choice. + 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. - AnyEvent::Impl::Glib based on Glib, third-best choice. - AnyEvent::Impl::Tk based on Tk, very bad choice. - AnyEvent::Impl::Qt based on Qt, cannot be autoprobed (see its docs). + + Backends that are transparently being picked up when they are used. + These will be used when they are currently loaded when the first + watcher is created, in which case it is assumed that the application + is using them. This means that AnyEvent will automatically pick the + right backend when the main program loads an event module before + anything starts to create watchers. Nothing special needs to be done + by the main program. + + 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, not generic enough for full support. + AnyEvent::Impl::POE based on POE, very slow, some limitations. + + Backends with special needs. + Qt requires the Qt::Application to be instantiated first, but will + otherwise be picked up automatically. As long as the main program + instantiates the application before any AnyEvent watchers are + created, everything should just work. + + AnyEvent::Impl::Qt based on Qt. + + Support for IO::Async can only be partial, as it is too broken and + architecturally limited to even support the AnyEvent API. It also is + the only event loop that needs the loop to be set explicitly, so it + can only be used by a main program knowing about AnyEvent. See + AnyEvent::Impl::Async for the gory details. + + AnyEvent::Impl::IOAsync based on IO::Async, cannot be autoprobed. - There is no support for WxWidgets, as WxWidgets has no support for - watching file handles. However, you can use WxWidgets through the - POE Adaptor, as POE has a Wx backend that simply polls 20 times per - second, which was considered to be too horrible to even consider for - AnyEvent. Likewise, other POE backends can be used by AnyEvent by - using it's adaptor. + Event loops that are indirectly supported via other backends. + Some event loops can be supported via other modules: - AnyEvent knows about Prima and Wx and will try to use POE when - autodetecting them. + There is no direct support for WxWidgets (Wx) or Prima. + + WxWidgets has no support for watching file handles. However, you can + use WxWidgets through the POE adaptor, as POE has a Wx backend that + simply polls 20 times per second, which was considered to be too + horrible to even consider for AnyEvent. + + Prima is not supported as nobody seems to be using it, but it has a + POE backend, so it can be supported through POE. + + AnyEvent knows about both Prima and Wx, however, and will try to + load POE when detecting them, in the hope that POE will pick them + up, in which case everything will be automatic. + +GLOBAL VARIABLES AND FUNCTIONS + These are not normally required to use AnyEvent, but can be useful to + write AnyEvent extension modules. + + $AnyEvent::MODEL + Contains "undef" until the first watcher is being created, before + the backend has been autodetected. + + Afterwards it contains the event model that is being used, which is + the name of the Perl class implementing the model. This class is + usually one of the "AnyEvent::Impl:xxx" modules, but can be any + other class in the case AnyEvent has been extended at runtime (e.g. + in *rxvt-unicode* it will be "urxvt::anyevent"). AnyEvent::detect Returns $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. + possible at runtime, and not e.g. while initialising of your module. + + If you need to do some initialisation before AnyEvent watchers are + created, use "post_detect". $guard = AnyEvent::post_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). + The block will be executed *after* the actual backend has been + detected ($AnyEvent::MODEL is set), but *before* any watchers have + been created, so it is possible to e.g. patch @AnyEvent::ISA or do + other initialisations - see the sources of AnyEvent::Strict or + AnyEvent::AIO to see how this is used. + + The most common usage is to create some global watchers, without + forcing event module detection too early, for example, AnyEvent::AIO + creates and installs the global IO::AIO watcher in a "post_detect" + block to avoid autodetecting the event module at load time. + 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. @@ -729,10 +844,17 @@ after the event loop has been chosen. You should check $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. + 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. - Best use "AnyEvent::post_detect { BLOCK }" instead. + 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. WHAT TO DO IN A MODULE As a module author, you should "use AnyEvent" and call AnyEvent methods @@ -793,9 +915,9 @@ 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. + AnyEvent as a client and can therefore be mixed easily with other + AnyEvent modules and other event loops in the same program. Some of the + modules come with AnyEvent, most are available via CPAN. AnyEvent::Util Contains various utility functions that replace often-used but @@ -811,7 +933,7 @@ AnyEvent::Handle Provide read and write buffers, manages watchers for reads and writes, supports raw and formatted I/O, I/O queued and fully - transparent and non-blocking SSL/TLS. + transparent and non-blocking SSL/TLS (via AnyEvent::TLS. AnyEvent::DNS Provides rich asynchronous DNS resolver capabilities. @@ -842,16 +964,17 @@ A non-blocking interface to gpsd, a daemon delivering GPS information. - AnyEvent::IGS - A non-blocking interface to the Internet Go Server protocol (used by - App::IGS). - AnyEvent::IRC AnyEvent based IRC client module family (replacing the older Net::IRC3). - Net::XMPP2 - AnyEvent based XMPP (Jabber protocol) module family. + AnyEvent::XMPP + AnyEvent based XMPP (Jabber protocol) module family (replacing the + older Net::XMPP2>. + + AnyEvent::IGS + A non-blocking interface to the Internet Go Server protocol (used by + App::IGS). Net::FCP AnyEvent-based implementation of the Freenet Client Protocol, @@ -863,10 +986,6 @@ Coro Has special support for AnyEvent via Coro::AnyEvent. - IO::Lambda - The lambda approach to I/O - don't ask, look there. Can use - AnyEvent. - 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 @@ -903,18 +1022,23 @@ When set to 2 or higher, cause AnyEvent to report to STDERR which event model it chooses. + When set to 8 or higher, then AnyEvent will report extra information + on which optional modules it loads and how it implements certain + features. + "PERL_ANYEVENT_STRICT" AnyEvent does not do much argument checking by default, as thorough argument checking is very costly. Setting this variable to a true value will cause AnyEvent to load "AnyEvent::Strict" and then to thoroughly check the arguments passed to most method calls. If it - finds any problems it will croak. + finds any problems, it will croak. In other words, enables "strict" mode. - Unlike "use strict", it is definitely recommended ot keep it off in - production. Keeping "PERL_ANYEVENT_STRICT=1" in your environment - while developing programs can be very useful, however. + Unlike "use strict" (or it's modern cousin, "use common::sense", it + is definitely recommended to keep it off in production. Keeping + "PERL_ANYEVENT_STRICT=1" in your environment while developing + programs can be very useful, however. "PERL_ANYEVENT_MODEL" This can be used to specify the event model to be used by AnyEvent, @@ -966,6 +1090,26 @@ The maximum number of child processes that "AnyEvent::Util::fork_call" will create in parallel. + "PERL_ANYEVENT_MAX_OUTSTANDING_DNS" + The default value for the "max_outstanding" parameter for the + default DNS resolver - this is the maximum number of parallel DNS + requests that are sent to the DNS server. + + "PERL_ANYEVENT_RESOLV_CONF" + The file to use instead of /etc/resolv.conf (or OS-specific + configuration) in the default resolver. When set to the empty + string, no default config will be used. + + "PERL_ANYEVENT_CA_FILE", "PERL_ANYEVENT_CA_PATH". + When neither "ca_file" nor "ca_path" was specified during + AnyEvent::TLS context creation, and either of these environment + variables exist, they will be used to specify CA certificate + locations instead of a system-dependent default. + + "PERL_ANYEVENT_AVOID_GUARD" and "PERL_ANYEVENT_AVOID_ASYNC_INTERRUPT" + When these are set to 1, then the respective modules are not loaded. + Mostly good for testing AnyEvent itself. + SUPPLYING YOUR OWN EVENT MODEL INTERFACE This is an advanced topic that you do not normally need to use AnyEvent in a module. This section is only of use to event loop authors who want @@ -1210,6 +1354,8 @@ 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 @@ -1249,6 +1395,9 @@ The "Event" module has a relatively high setup and callback invocation cost, but overall scores in on the third place. + "IO::Async" performs admirably well, about on par with "Event", even + when using its pure perl backend. + "Glib"'s memory usage is quite a bit higher, but it features a faster callback invocation and overall ends up in the same class as "Event". However, Glib scales extremely badly, doubling the number of watchers @@ -1328,12 +1477,14 @@ and creating a new one that moves the timeout into the future. Results - name sockets create request - EV 20000 69.01 11.16 - 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 + 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 Discussion This benchmark *does* measure scalability and overall performance of the @@ -1345,6 +1496,9 @@ Perl surprisingly comes second. It is much faster than the C-based event loops Event and Glib. + IO::Async performs very well when using its epoll backend, and still + quite good compared to Glib when using its pure perl backend. + Event suffers from high setup time as well (look at its code and you will understand why). Callback invocation also has a high overhead compared to the "$_->() for .."-style loop that the Perl event loop @@ -1409,16 +1563,16 @@ could be misinterpreted to make AnyEvent look bad. In fact, the benchmark simply compares IO::Lambda with POE, and IO::Lambda looks better (which shouldn't come as a surprise to anybody). As such, the - benchmark is fine, and shows that the AnyEvent backend from IO::Lambda - isn't very optimal. But how would AnyEvent compare when used without the - extra baggage? To explore this, I wrote the equivalent benchmark for - AnyEvent. + benchmark is fine, and mostly shows that the AnyEvent backend from + IO::Lambda isn't very optimal. But how would AnyEvent compare when used + without the extra baggage? To explore this, I wrote the equivalent + benchmark for AnyEvent. The benchmark itself creates an echo-server, and then, for 500 times, connects to the echo server, sends a line, waits for the reply, and then creates the next connection. This is a rather bad benchmark, as it - doesn't test the efficiency of the framework, but it is a benchmark - nevertheless. + doesn't test the efficiency of the framework or much non-blocking I/O, + but it is a benchmark nevertheless. name runtime Lambda/select 0.330 sec @@ -1434,33 +1588,32 @@ AnyEvent/EV/nb 0.068 sec +state machine 0.134 sec - The benchmark is also a bit unfair (my fault) - the IO::Lambda + The benchmark is also a bit unfair (my fault): the IO::Lambda/POE benchmarks actually make blocking connects and use 100% blocking I/O, defeating the purpose of an event-based solution. All of the newly written AnyEvent benchmarks use 100% non-blocking connects (using AnyEvent::Socket::tcp_connect and the asynchronous pure perl DNS - resolver), so AnyEvent is at a disadvantage here as non-blocking + resolver), so AnyEvent is at a disadvantage here, as non-blocking connects generally require a lot more bookkeeping and event handling than blocking connects (which involve a single syscall only). The last AnyEvent benchmark additionally uses AnyEvent::Handle, which - offers similar expressive power as POE and IO::Lambda (using - conventional Perl syntax), which means both the echo server and the - client are 100% non-blocking w.r.t. I/O, further placing it at a - disadvantage. - - As you can see, AnyEvent + EV even beats the hand-optimised "raw sockets - benchmark", while AnyEvent + its pure perl backend easily beats - IO::Lambda and POE. + offers similar expressive power as POE and IO::Lambda, using + conventional Perl syntax. This means that both the echo server and the + client are 100% non-blocking, further placing it at a disadvantage. + + 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, even - thought it does all of DNS, tcp-connect and socket I/O in a non-blocking - way. - - The two AnyEvent benchmarks 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. + 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. + + 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. SIGNALS AnyEvent currently installs handlers for these signals: @@ -1470,6 +1623,10 @@ emulation for event loops that do not support them natively. Also, some event loops install a similar handler. + Additionally, when AnyEvent is loaded and SIGCHLD is set to IGNORE, + then AnyEvent will reset it to default, to avoid losing child exit + statuses. + SIGPIPE A no-op handler is installed for "SIGPIPE" when $SIG{PIPE} is "undef" when AnyEvent gets loaded. @@ -1486,13 +1643,82 @@ Feel free to install your own handler, or reset it to defaults. +RECOMMENDED/OPTIONAL MODULES + One of AnyEvent's main goals is to be 100% Pure-Perl(tm): only perl (and + 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 + they affect AnyEvent's operetion. + + 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 + signals still get delivered, AnyEvent will start an interval timer + to wake up perl (and catch the signals) with some delay (default is + 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). + + 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 + natively, and either employ their own workarounds (POE) or use + AnyEvent's workaround (using $AnyEvent::MAX_SIGNAL_LATENCY). + Installing Async::Interrupt does nothing for those backends. + + EV This module isn't really "optional", as it is simply one of the + backend event loops that AnyEvent can use. However, it is simply the + best event loop available in terms of features, speed and stability: + It supports the AnyEvent API optimally, implements all the watcher + types in XS, does automatic timer adjustments even when no monotonic + 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). + + 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 + 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 + 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. + + Time::HiRes + This module is part of perl since release 5.008. It will be used + when the chosen event library does not come with a timing source on + it's own. The pure-perl event loop (AnyEvent::Impl::Perl) will + 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. Only EV is fully fork-aware. 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. + watcher OR you must not use AnyEvent at all in the child OR you must do + something completely out of the scope of AnyEvent. SECURITY CONSIDERATIONS AnyEvent can be forced to load any event model via @@ -1514,6 +1740,10 @@ is probably even less useful to an attacker than PERL_ANYEVENT_MODEL), and $ENV{PERL_ANYEVENT_STRICT}. + Note that AnyEvent will remove *all* environment variables starting with + "PERL_ANYEVENT_" from %ENV when it is loaded while taint mode is + enabled. + BUGS Perl 5.8 has numerous memleaks that sometimes hit this module and are hard to work around. If you suffer from memleaks, first upgrade to Perl @@ -1529,16 +1759,18 @@ 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::EventLib, AnyEvent::Impl::Qt, AnyEvent::Impl::POE, + AnyEvent::Impl::IOAsync. Non-blocking file handles, sockets, TCP clients and servers: - AnyEvent::Handle, AnyEvent::Socket. + AnyEvent::Handle, AnyEvent::Socket, AnyEvent::TLS. Asynchronous DNS: AnyEvent::DNS. Coroutine support: Coro, Coro::AnyEvent, Coro::EV, Coro::Event, - Nontrivial usage examples: Net::FCP, Net::XMPP2, AnyEvent::DNS. + Nontrivial usage examples: AnyEvent::GPSD, AnyEvent::XMPP, + AnyEvent::HTTP. AUTHOR Marc Lehmann