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

Comparing AnyEvent/README (file contents):
Revision 1.70 by root, Fri Apr 13 09:57:41 2012 UTC vs.
Revision 1.71 by root, Wed Aug 21 08:40:28 2013 UTC

262 262
263 Example 2: fire an event after 0.5 seconds, then roughly every second. 263 Example 2: fire an event after 0.5 seconds, then roughly every second.
264 264
265 my $w = AnyEvent->timer (after => 0.5, interval => 1, cb => sub { 265 my $w = AnyEvent->timer (after => 0.5, interval => 1, cb => sub {
266 warn "timeout\n"; 266 warn "timeout\n";
267 }; 267 });
268 268
269 TIMING ISSUES 269 TIMING ISSUES
270 There are two ways to handle timers: based on real time (relative, "fire 270 There are two ways to handle timers: based on real time (relative, "fire
271 in 10 seconds") and based on wallclock time (absolute, "fire at 12 271 in 10 seconds") and based on wallclock time (absolute, "fire at 12
272 o'clock"). 272 o'clock").
736 }; 736 };
737 } 737 }
738 738
739 $cv->end; 739 $cv->end;
740 740
741 ...
742
743 my $results = $cv->recv;
744
741 This code fragment supposedly pings a number of hosts and calls 745 This code fragment supposedly pings a number of hosts and calls
742 "send" after results for all then have have been gathered - in any 746 "send" after results for all then have have been gathered - in any
743 order. To achieve this, the code issues a call to "begin" when it 747 order. To achieve this, the code issues a call to "begin" when it
744 starts each ping request and calls "end" when it has received some 748 starts each ping request and calls "end" when it has received some
745 result for it. Since "begin" and "end" only maintain a counter, the 749 result for it. Since "begin" and "end" only maintain a counter, the
774 In list context, all parameters passed to "send" will be returned, 778 In list context, all parameters passed to "send" will be returned,
775 in scalar context only the first one will be returned. 779 in scalar context only the first one will be returned.
776 780
777 Note that doing a blocking wait in a callback is not supported by 781 Note that doing a blocking wait in a callback is not supported by
778 any event loop, that is, recursive invocation of a blocking "->recv" 782 any event loop, that is, recursive invocation of a blocking "->recv"
779 is not allowed, and the "recv" call will "croak" if such a condition 783 is not allowed and the "recv" call will "croak" if such a condition
780 is detected. This condition can be slightly loosened by using 784 is detected. This requirement can be dropped by relying on
781 Coro::AnyEvent, which allows you to do a blocking "->recv" from any 785 Coro::AnyEvent , which allows you to do a blocking "->recv" from any
782 thread that doesn't run the event loop itself. 786 thread that doesn't run the event loop itself. Coro::AnyEvent is
787 loaded automatically when Coro is used with AnyEvent, so code does
788 not need to do anything special to take advantage of that: any code
789 that would normally block your program because it calls "recv", be
790 executed in an "async" thread instead without blocking other
791 threads.
783 792
784 Not all event models support a blocking wait - some die in that case 793 Not all event models support a blocking wait - some die in that case
785 (programs might want to do that to stay interactive), so *if you are 794 (programs might want to do that to stay interactive), so *if you are
786 using this from a module, never require a blocking wait*. Instead, 795 using this from a module, never require a blocking wait*. Instead,
787 let the caller decide whether the call will block or not (for 796 let the caller decide whether the call will block or not (for
1082 modules come as part of AnyEvent, the others are available via CPAN (see 1091 modules come as part of AnyEvent, the others are available via CPAN (see
1083 <http://search.cpan.org/search?m=module&q=anyevent%3A%3A*> for a longer 1092 <http://search.cpan.org/search?m=module&q=anyevent%3A%3A*> for a longer
1084 non-exhaustive list), and the list is heavily biased towards modules of 1093 non-exhaustive list), and the list is heavily biased towards modules of
1085 the AnyEvent author himself :) 1094 the AnyEvent author himself :)
1086 1095
1087 AnyEvent::Util 1096 AnyEvent::Util (part of the AnyEvent distribution)
1088 Contains various utility functions that replace often-used blocking 1097 Contains various utility functions that replace often-used blocking
1089 functions such as "inet_aton" with event/callback-based versions. 1098 functions such as "inet_aton" with event/callback-based versions.
1090 1099
1091 AnyEvent::Socket 1100 AnyEvent::Socket (part of the AnyEvent distribution)
1092 Provides various utility functions for (internet protocol) sockets, 1101 Provides various utility functions for (internet protocol) sockets,
1093 addresses and name resolution. Also functions to create non-blocking 1102 addresses and name resolution. Also functions to create non-blocking
1094 tcp connections or tcp servers, with IPv6 and SRV record support and 1103 tcp connections or tcp servers, with IPv6 and SRV record support and
1095 more. 1104 more.
1096 1105
1097 AnyEvent::Handle 1106 AnyEvent::Handle (part of the AnyEvent distribution)
1098 Provide read and write buffers, manages watchers for reads and 1107 Provide read and write buffers, manages watchers for reads and
1099 writes, supports raw and formatted I/O, I/O queued and fully 1108 writes, supports raw and formatted I/O, I/O queued and fully
1100 transparent and non-blocking SSL/TLS (via AnyEvent::TLS). 1109 transparent and non-blocking SSL/TLS (via AnyEvent::TLS).
1101 1110
1102 AnyEvent::DNS 1111 AnyEvent::DNS (part of the AnyEvent distribution)
1103 Provides rich asynchronous DNS resolver capabilities. 1112 Provides rich asynchronous DNS resolver capabilities.
1104 1113
1105 AnyEvent::HTTP, AnyEvent::IRC, AnyEvent::XMPP, AnyEvent::GPSD, 1114 AnyEvent::HTTP, AnyEvent::IRC, AnyEvent::XMPP, AnyEvent::GPSD,
1106 AnyEvent::IGS, AnyEvent::FCP 1115 AnyEvent::IGS, AnyEvent::FCP
1107 Implement event-based interfaces to the protocols of the same name 1116 Implement event-based interfaces to the protocols of the same name
1108 (for the curious, IGS is the International Go Server and FCP is the 1117 (for the curious, IGS is the International Go Server and FCP is the
1109 Freenet Client Protocol). 1118 Freenet Client Protocol).
1110 1119
1111 AnyEvent::AIO 1120 AnyEvent::AIO (part of the AnyEvent distribution)
1112 Truly asynchronous (as opposed to non-blocking) I/O, should be in 1121 Truly asynchronous (as opposed to non-blocking) I/O, should be in
1113 the toolbox of every event programmer. AnyEvent::AIO transparently 1122 the toolbox of every event programmer. AnyEvent::AIO transparently
1114 fuses IO::AIO and AnyEvent together, giving AnyEvent access to 1123 fuses IO::AIO and AnyEvent together, giving AnyEvent access to
1115 event-based file I/O, and much more. 1124 event-based file I/O, and much more.
1116 1125
2001 This module is part of perl since release 5.008. It will be used 2010 This module is part of perl since release 5.008. It will be used
2002 when the chosen event library does not come with a timing source of 2011 when the chosen event library does not come with a timing source of
2003 its own. The pure-perl event loop (AnyEvent::Loop) will additionally 2012 its own. The pure-perl event loop (AnyEvent::Loop) will additionally
2004 load it to try to use a monotonic clock for timing stability. 2013 load it to try to use a monotonic clock for timing stability.
2005 2014
2015 AnyEvent::AIO (and IO::AIO)
2016 The default implementation of AnyEvent::IO is to do I/O
2017 synchronously, stopping programs while they access the disk, which
2018 is fine for a lot of programs.
2019
2020 Installing AnyEvent::AIO (and its IO::AIO dependency) makes it
2021 switch to a true asynchronous implementation, so event processing
2022 can continue even while waiting for disk I/O.
2023
2006FORK 2024FORK
2007 Most event libraries are not fork-safe. The ones who are usually are 2025 Most event libraries are not fork-safe. The ones who are usually are
2008 because they rely on inefficient but fork-safe "select" or "poll" calls 2026 because they rely on inefficient but fork-safe "select" or "poll" calls
2009 - higher performance APIs such as BSD's kqueue or the dreaded Linux 2027 - higher performance APIs such as BSD's kqueue or the dreaded Linux
2010 epoll are usually badly thought-out hacks that are incompatible with 2028 epoll are usually badly thought-out hacks that are incompatible with

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines