ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/AnyEvent/README
(Generate patch)

Comparing AnyEvent/README (file contents):
Revision 1.58 by root, Sun Dec 20 22:49:52 2009 UTC vs.
Revision 1.59 by root, Tue Jan 5 10:45:25 2010 UTC

486 $done->recv; 486 $done->recv;
487 487
488 IDLE WATCHERS 488 IDLE WATCHERS
489 $w = AnyEvent->idle (cb => <callback>); 489 $w = AnyEvent->idle (cb => <callback>);
490 490
491 Sometimes there is a need to do something, but it is not so important to 491 Repeatedly invoke the callback after the process becomes idle, until
492 do it instantly, but only when there is nothing better to do. This 492 either the watcher is destroyed or new events have been detected.
493 "nothing better to do" is usually defined to be "no other events need
494 attention by the event loop".
495 493
496 Idle watchers ideally get invoked when the event loop has nothing better 494 Idle watchers are useful when there is a need to do something, but it is
497 to do, just before it would block the process to wait for new events. 495 not so important (or wise) to do it instantly. The callback will be
498 Instead of blocking, the idle watcher is invoked. 496 invoked only when there is "nothing better to do", which is usually
497 defined as "all outstanding events have been handled and no new events
498 have been detected". That means that idle watchers ideally get invoked
499 when the event loop has just polled for new events but none have been
500 detected. Instead of blocking to wait for more events, the idle watchers
501 will be invoked.
499 502
500 Most event loops unfortunately do not really support idle watchers (only 503 Unfortunately, most event loops do not really support idle watchers
501 EV, Event and Glib do it in a usable fashion) - for the rest, AnyEvent 504 (only EV, Event and Glib do it in a usable fashion) - for the rest,
502 will simply call the callback "from time to time". 505 AnyEvent will simply call the callback "from time to time".
503 506
504 Example: read lines from STDIN, but only process them when the program 507 Example: read lines from STDIN, but only process them when the program
505 is otherwise idle: 508 is otherwise idle:
506 509
507 my @lines; # read data 510 my @lines; # read data
1800 additionally use it to try to use a monotonic clock for timing 1803 additionally use it to try to use a monotonic clock for timing
1801 stability. 1804 stability.
1802 1805
1803FORK 1806FORK
1804 Most event libraries are not fork-safe. The ones who are usually are 1807 Most event libraries are not fork-safe. The ones who are usually are
1805 because they rely on inefficient but fork-safe "select" or "poll" calls. 1808 because they rely on inefficient but fork-safe "select" or "poll" calls
1806 Only EV is fully fork-aware. 1809 - higher performance APIs such as BSD's kqueue or the dreaded Linux
1810 epoll are usually badly thought-out hacks that are incompatible with
1811 fork in one way or another. Only EV is fully fork-aware and ensures that
1812 you continue event-processing in both parent and child (or both, if you
1813 know what you are doing).
1807 1814
1808 This means that, in general, you cannot fork and do event processing in 1815 This means that, in general, you cannot fork and do event processing in
1809 the child if a watcher was created before the fork (which in turn 1816 the child if the event library was initialised before the fork (which
1810 initialises the event library). 1817 usually happens when the first AnyEvent watcher is created, or the
1818 library is loaded).
1811 1819
1812 If you have to fork, you must either do so *before* creating your first 1820 If you have to fork, you must either do so *before* creating your first
1813 watcher OR you must not use AnyEvent at all in the child OR you must do 1821 watcher OR you must not use AnyEvent at all in the child OR you must do
1814 something completely out of the scope of AnyEvent. 1822 something completely out of the scope of AnyEvent.
1815 1823
1816 The problem of doing event processing in the parent *and* the child is 1824 The problem of doing event processing in the parent *and* the child is
1817 much more complicated: even for backends that *are* fork-aware or 1825 much more complicated: even for backends that *are* fork-aware or
1818 fork-safe, their behaviour is not usually what you want: fork clones all 1826 fork-safe, their behaviour is not usually what you want: fork clones all
1819 watchers, that means all timers, I/O watchers etc. are active in both 1827 watchers, that means all timers, I/O watchers etc. are active in both
1820 parent and child, which is almost never what you want. 1828 parent and child, which is almost never what you want. USing "exec" to
1829 start worker children from some kind of manage rprocess is usually
1830 preferred, because it is much easier and cleaner, at the expense of
1831 having to have another binary.
1821 1832
1822SECURITY CONSIDERATIONS 1833SECURITY CONSIDERATIONS
1823 AnyEvent can be forced to load any event model via 1834 AnyEvent can be forced to load any event model via
1824 $ENV{PERL_ANYEVENT_MODEL}. While this cannot (to my knowledge) be used 1835 $ENV{PERL_ANYEVENT_MODEL}. While this cannot (to my knowledge) be used
1825 to execute arbitrary code or directly gain access, it can easily be used 1836 to execute arbitrary code or directly gain access, it can easily be used

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines