--- AnyEvent/README 2009/12/05 02:52:03 1.57 +++ AnyEvent/README 2010/04/28 14:15:55 1.61 @@ -7,7 +7,10 @@ SYNOPSIS use AnyEvent; - # file descriptor readable + # if you prefer function calls, look at the L manpage for + # an alternative API. + + # file handle or descriptor readable my $w = AnyEvent->io (fh => $fh, poll => "r", cb => sub { ... }); # one-shot or repeating timers @@ -470,10 +473,10 @@ Example: fork a process and wait for it my $done = AnyEvent->condvar; - - my $pid = fork or exit 5; - - my $w = AnyEvent->child ( + + my $pid = fork or exit 5; + + my $w = AnyEvent->child ( pid => $pid, cb => sub { my ($pid, $status) = @_; @@ -481,25 +484,28 @@ $done->send; }, ); - - # do something else, then wait for process exit + + # do something else, then wait for process exit $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 - attention by the event loop". - - Idle watchers ideally get invoked when the event loop has nothing better - to do, just before it would block the process to wait for new events. - Instead of blocking, the idle watcher is invoked. - - Most event loops unfortunately do not really support idle watchers (only - EV, Event and Glib do it in a usable fashion) - for the rest, AnyEvent - will simply call the callback "from time to time". + Repeatedly invoke the callback after the process becomes idle, until + either the watcher is destroyed or new events have been detected. + + Idle watchers are useful when there is a need to do something, but it is + not so important (or wise) to do it instantly. The callback will be + invoked only when there is "nothing better to do", which is usually + defined as "all outstanding events have been handled and no new events + have been detected". That means that idle watchers ideally get invoked + when the event loop has just polled for new events but none have been + detected. Instead of blocking to wait for more events, the idle watchers + will be invoked. + + Unfortunately, most event loops do not really support idle watchers + (only EV, Event and Glib do it in a usable fashion) - for the rest, + AnyEvent will simply call the callback "from time to time". Example: read lines from STDIN, but only process them when the program is otherwise idle: @@ -588,21 +594,21 @@ Example: wait for a timer. - # wait till the result is ready - my $result_ready = AnyEvent->condvar; + # condition: "wait till the timer is fired" + my $timer_fired = AnyEvent->condvar; - # do something such as adding a timer - # or socket watcher the calls $result_ready->send - # when the "result" is ready. + # create the timer - we could wait for, say + # a handle becomign ready, or even an + # AnyEvent::HTTP request to finish, but # in this case, we simply use a timer: my $w = AnyEvent->timer ( after => 1, - cb => sub { $result_ready->send }, + cb => sub { $timer_fired->send }, ); # this "blocks" (while handling events) till the callback # calls ->send - $result_ready->recv; + $timer_fired->recv; Example: wait for a timer, but take advantage of the fact that condition variables are also callable directly. @@ -921,7 +927,7 @@ 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. + allows it, as it takes care of these details. This variable is mainly useful for modules that can do something useful when AnyEvent is used and thus want to know when it is @@ -929,6 +935,19 @@ provides the means to hook into AnyEvent passively, without loading it. + Example: To load Coro::AnyEvent whenever Coro and AnyEvent are used + together, you could put this into Coro (this is the actual code used + by Coro to accomplish this): + + if (defined $AnyEvent::MODEL) { + # AnyEvent already initialised, so load Coro::AnyEvent + require Coro::AnyEvent; + } else { + # AnyEvent not yet initialised, so make sure to load Coro::AnyEvent + # as soon as it is + push @AnyEvent::post_detect, sub { require Coro::AnyEvent }; + } + WHAT TO DO IN A MODULE As a module author, you should "use AnyEvent" and call AnyEvent methods freely, but you should not load a specific event module or rely on it. @@ -1062,7 +1081,7 @@ 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. + overhead by using function call syntax and a fixed number of parameters. See the AE manpage for details. @@ -1337,7 +1356,7 @@ exceptions) that occurred during request processing. The "result" method detects whether an exception as thrown (it is stored inside the $txn object) and just throws the exception, which means connection errors and - other problems get reported tot he code that tries to use the result, + other problems get reported to the code that tries to use the result, not in a random callback. All of this enables the following usage styles: @@ -1760,6 +1779,9 @@ You can even embed Glib/Gtk2 in it (or vice versa, see EV::Glib and Glib::EV). + If you only use backends that rely on another event loop (e.g. + "Tk"), then this module will do nothing for you. + Guard The guard module, when used, will be used to implement "AnyEvent::Util::guard". This speeds up guards considerably (and @@ -1768,12 +1790,9 @@ JSON and JSON::XS 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 - installed. + data via AnyEvent::Handle. JSON is also written in pure-perl, but + can take advantage of the ultra-high-speed JSON::XS module when it + is installed. Net::SSLeay Implementing TLS/SSL in Perl is certainly interesting, but not very @@ -1789,12 +1808,17 @@ 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. + because they rely on inefficient but fork-safe "select" or "poll" calls + - higher performance APIs such as BSD's kqueue or the dreaded Linux + epoll are usually badly thought-out hacks that are incompatible with + fork in one way or another. Only EV is fully fork-aware and ensures that + you continue event-processing in both parent and child (or both, if you + know what you are doing). This means that, in general, you cannot fork and do event processing in - the child if a watcher was created before the fork (which in turn - initialises the event library). + the child if the event library was initialised before the fork (which + usually happens when the first AnyEvent watcher is created, or the + library is loaded). 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 OR you must do @@ -1804,7 +1828,10 @@ much more complicated: even for backends that *are* fork-aware or fork-safe, their behaviour is not usually what you want: fork clones all watchers, that means all timers, I/O watchers etc. are active in both - parent and child, which is almost never what you want. + parent and child, which is almost never what you want. USing "exec" to + start worker children from some kind of manage rprocess is usually + preferred, because it is much easier and cleaner, at the expense of + having to have another binary. SECURITY CONSIDERATIONS AnyEvent can be forced to load any event model via @@ -1818,8 +1845,8 @@ before the first watcher gets created, e.g. with a "BEGIN" block: BEGIN { delete $ENV{PERL_ANYEVENT_MODEL} } - - use AnyEvent; + + 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