--- AnyEvent/README 2009/08/09 16:05:11 1.51 +++ AnyEvent/README 2009/12/20 22:49:52 1.58 @@ -356,6 +356,14 @@ 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 @@ -386,6 +394,21 @@ my $w = AnyEvent->signal (signal => "INT", cb => sub { exit 1 }); + Restart Behaviour + While restart behaviour is up to the event loop implementation, most + will not restart syscalls (that includes Async::Interrupt and AnyEvent's + pure perl implementation). + + Safe/Unsafe Signals + Perl signals can be either "safe" (synchronous to opcode handling) or + "unsafe" (asynchronous) - the former might get delayed indefinitely, the + latter might corrupt your memory. + + AnyEvent signal handlers are, in addition, synchronous to the event + loop, i.e. they will not interrupt your running perl program but will + only be called as part of the normal event handling (just like timer, + I/O etc. callbacks, too). + 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 @@ -578,7 +601,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 +668,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 +709,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; @@ -897,7 +921,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 @@ -905,6 +929,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. @@ -1229,16 +1266,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 @@ -1666,13 +1696,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: @@ -1709,8 +1739,8 @@ 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. + This section explains which additional modules will be used, and how + they affect AnyEvent's operation. Async::Interrupt This slightly arcane module is used to implement fast signal @@ -1723,7 +1753,7 @@ 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). + 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). @@ -1750,9 +1780,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 @@ -1775,10 +1805,20 @@ because they rely on inefficient but fork-safe "select" or "poll" calls. Only EV is fully fork-aware. + 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). + 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 something completely out of the scope of AnyEvent. + The problem of doing event processing in the parent *and* the child is + 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. + SECURITY CONSIDERATIONS AnyEvent can be forced to load any event model via $ENV{PERL_ANYEVENT_MODEL}. While this cannot (to my knowledge) be used