[ViewVC] Diff of: cvs/AnyEvent/lib/AnyEvent.pm

Comparing AnyEvent/lib/AnyEvent.pm (file contents):
Revision 1.290 by root, Tue Sep 1 18:27:46 2009 UTC vs.
Revision 1.309 by root, Sat Dec 26 08:59:35 2009 UTC

 might affect timers and time-outs.
 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. C<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 C<<
+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 I<might> cause some events to be handled.
 =back
 =head2 SIGNAL WATCHERS
 correctly.
 Example: exit on SIGINT
    my $w = AnyEvent->signal (signal => "INT", cb => sub { exit 1 });
+=head3 Restart Behaviour
+While restart behaviour is up to the event loop implementation, most will
+not restart syscalls (that includes L<Async::Interrupt> and AnyEvent's
+pure perl implementation).
+=head3 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).
 =head3 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
 =head2 IDLE WATCHERS
    $w = AnyEvent->idle (cb => <callback>);
-Sometimes there is a need to do something, but it is not so important
+Repeatedly invoke the callback after the process becomes idle, until
-to do it instantly, but only when there is nothing better to do. This
+either the watcher is destroyed or new events have been detected.
-"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
+Idle watchers are useful when there is a need to do something, but it
-better to do, just before it would block the process to wait for new
+is not so important (or wise) to do it instantly. The callback will be
-events. Instead of blocking, the idle watcher is invoked.
+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.
-Most event loops unfortunately do not really support idle watchers (only
+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:
 You should check C<$AnyEvent::MODEL> before adding to this array, though:
 if it is defined then the event loop has already been detected, and the
 array will be ignored.
 Best use C<AnyEvent::post_detect { BLOCK }> when your application allows
-it,as it takes care of these details.
+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 initialised, but do
 not need to even load it by default. This array 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 };
+   }
 =back
 =head1 WHAT TO DO IN A MODULE
 package AnyEvent;
 # basically a tuned-down version of common::sense
 sub common_sense {
    # from common:.sense 1.0
-   ${^WARNING_BITS} = "\xfc\x3f\xf3\x00\x0f\xf3\xcf\xc0\xf3\xfc\x33\x03";
+   ${^WARNING_BITS} = "\xfc\x3f\x33\x00\x0f\xf3\xcf\xc0\xf3\xfc\x33\x00";
-   # use strict vars subs
+   # use strict vars subs - NO UTF-8, as Util.pm doesn't like this atm. (uts46data.pl)
    $^H |= 0x00000600;
 }
 BEGIN { AnyEvent::common_sense }
 use Carp ();
-our $VERSION = '5.12';
+our $VERSION = '5.23';
 our $MODEL;
 our $AUTOLOAD;
 our @ISA;
 our @REGISTRY;
-our $WIN32;
 our $VERBOSE;
 BEGIN {
    eval "sub WIN32(){ " . (($^O =~ /mswin32/i)*1) ." }";
 our ($SIG_COUNT, $SIG_TW);
 sub _signal_exec {
    $HAVE_ASYNC_INTERRUPT
       ? $SIGPIPE_R->drain
-      : sysread $SIGPIPE_R, my $dummy, 9;
+      : sysread $SIGPIPE_R, (my $dummy), 9;
    while (%SIG_EV) {
       for (keys %SIG_EV) {
          delete $SIG_EV{$_};
          $_->() for values %{ $SIG_CB{$_} || {} };
 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
+This section explains which additional modules will be used, and how they
-affect AnyEvent's operetion.
+affect AnyEvent's operation.
 =over 4
 =item L<Async::Interrupt>
 catch the signals) with some delay (default is 10 seconds, look for
 C<$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
+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).
 lot less memory), but otherwise doesn't affect guard operation much. It is
 purely used for performance.
 =item L<JSON> and L<JSON::XS>
-This module is required when you want to read or write JSON data via
+One of these modules is required when you want to read or write JSON data
-L<AnyEvent::Handle>. It is also written in pure-perl, but can take
+via L<AnyEvent::Handle>. It is also written in pure-perl, but can take
 advantage of the ultra-high-speed L<JSON::XS> module when it is installed.
 In fact, L<AnyEvent::Handle> will use L<JSON::XS> by default if it is
 installed.
 =head1 FORK
 Most event libraries are not fork-safe. The ones who are usually are
-because they rely on inefficient but fork-safe C<select> or C<poll>
+because they rely on inefficient but fork-safe C<select> or C<poll> calls
-calls. Only L<EV> is fully fork-aware.
+- 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 L<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 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 I<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 I<and> the child
+is much more complicated: even for backends that I<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. USing C<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.
 =head1 SECURITY CONSIDERATIONS
 AnyEvent can be forced to load any event model via

Diff Legend

-–
+Removed lines
-+
+Added lines
-<
+Changed lines
->
+Changed lines

Comparing AnyEvent/lib/AnyEvent.pm (file contents): Revision 1.290 by root, Tue Sep 1 18:27:46 2009 UTC vs. Revision 1.309 by root, Sat Dec 26 08:59:35 2009 UTC

Diff Legend

Comparing AnyEvent/lib/AnyEvent.pm (file contents):
Revision 1.290 by root, Tue Sep 1 18:27:46 2009 UTC vs.
Revision 1.309 by root, Sat Dec 26 08:59:35 2009 UTC