--- AnyEvent/README 2009/07/18 05:19:09 1.46 +++ AnyEvent/README 2009/08/01 09:14:54 1.50 @@ -1,8 +1,8 @@ NAME - AnyEvent - provide framework for multiple event loops + 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; @@ -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 + 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 nowadays. So what is different about AnyEvent? @@ -168,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: @@ -205,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: @@ -338,6 +359,8 @@ 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. @@ -359,28 +382,39 @@ programs overwriting those signals directly will likely not work correctly. - Also note that many event loops (e.g. Glib, Tk, Qt, IO::Async) do not - support attaching callbacks to signals, 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. - 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, 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, 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 @@ -429,6 +463,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 @@ -463,6 +499,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. @@ -492,7 +533,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 @@ -720,10 +762,11 @@ 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): @@ -750,6 +793,7 @@ 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 @@ -824,7 +868,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 @@ -1646,7 +1707,7 @@ 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 soemd elay (default is + 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 @@ -1657,6 +1718,11 @@ 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: @@ -1676,7 +1742,7 @@ 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 ulta-high-speed JSON::XS module when it is + 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 @@ -1743,7 +1809,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.