… | |
… | |
271 | |
271 | |
272 | Example 2: fire an event after 0.5 seconds, then roughly every second. |
272 | Example 2: fire an event after 0.5 seconds, then roughly every second. |
273 | |
273 | |
274 | my $w = AnyEvent->timer (after => 0.5, interval => 1, cb => sub { |
274 | my $w = AnyEvent->timer (after => 0.5, interval => 1, cb => sub { |
275 | warn "timeout\n"; |
275 | warn "timeout\n"; |
276 | }; |
276 | }); |
277 | |
277 | |
278 | =head3 TIMING ISSUES |
278 | =head3 TIMING ISSUES |
279 | |
279 | |
280 | There are two ways to handle timers: based on real time (relative, "fire |
280 | There are two ways to handle timers: based on real time (relative, "fire |
281 | in 10 seconds") and based on wallclock time (absolute, "fire at 12 |
281 | in 10 seconds") and based on wallclock time (absolute, "fire at 12 |
… | |
… | |
487 | |
487 | |
488 | Example: fork a process and wait for it |
488 | Example: fork a process and wait for it |
489 | |
489 | |
490 | my $done = AnyEvent->condvar; |
490 | my $done = AnyEvent->condvar; |
491 | |
491 | |
|
|
492 | # this forks and immediately calls exit in the child. this |
|
|
493 | # normally has all sorts of bad consequences for your parent, |
|
|
494 | # so take this as an example only. always fork and exec, |
|
|
495 | # or call POSIX::_exit, in real code. |
492 | my $pid = fork or exit 5; |
496 | my $pid = fork or exit 5; |
493 | |
497 | |
494 | my $w = AnyEvent->child ( |
498 | my $w = AnyEvent->child ( |
495 | pid => $pid, |
499 | pid => $pid, |
496 | cb => sub { |
500 | cb => sub { |
… | |
… | |
745 | This works because for every event source (EOF on file handle), there is |
749 | This works because for every event source (EOF on file handle), there is |
746 | one call to C<begin>, so the condvar waits for all calls to C<end> before |
750 | one call to C<begin>, so the condvar waits for all calls to C<end> before |
747 | sending. |
751 | sending. |
748 | |
752 | |
749 | The ping example mentioned above is slightly more complicated, as the |
753 | The ping example mentioned above is slightly more complicated, as the |
750 | there are results to be passwd back, and the number of tasks that are |
754 | there are results to be passed back, and the number of tasks that are |
751 | begun can potentially be zero: |
755 | begun can potentially be zero: |
752 | |
756 | |
753 | my $cv = AnyEvent->condvar; |
757 | my $cv = AnyEvent->condvar; |
754 | |
758 | |
755 | my %result; |
759 | my %result; |
… | |
… | |
763 | }; |
767 | }; |
764 | } |
768 | } |
765 | |
769 | |
766 | $cv->end; |
770 | $cv->end; |
767 | |
771 | |
|
|
772 | ... |
|
|
773 | |
|
|
774 | my $results = $cv->recv; |
|
|
775 | |
768 | This code fragment supposedly pings a number of hosts and calls |
776 | This code fragment supposedly pings a number of hosts and calls |
769 | C<send> after results for all then have have been gathered - in any |
777 | C<send> after results for all then have have been gathered - in any |
770 | order. To achieve this, the code issues a call to C<begin> when it starts |
778 | order. To achieve this, the code issues a call to C<begin> when it starts |
771 | each ping request and calls C<end> when it has received some result for |
779 | each ping request and calls C<end> when it has received some result for |
772 | it. Since C<begin> and C<end> only maintain a counter, the order in which |
780 | it. Since C<begin> and C<end> only maintain a counter, the order in which |
… | |
… | |
807 | |
815 | |
808 | In list context, all parameters passed to C<send> will be returned, |
816 | In list context, all parameters passed to C<send> will be returned, |
809 | in scalar context only the first one will be returned. |
817 | in scalar context only the first one will be returned. |
810 | |
818 | |
811 | Note that doing a blocking wait in a callback is not supported by any |
819 | Note that doing a blocking wait in a callback is not supported by any |
812 | event loop, that is, recursive invocation of a blocking C<< ->recv |
820 | event loop, that is, recursive invocation of a blocking C<< ->recv >> is |
813 | >> is not allowed, and the C<recv> call will C<croak> if such a |
821 | not allowed and the C<recv> call will C<croak> if such a condition is |
814 | condition is detected. This condition can be slightly loosened by using |
822 | detected. This requirement can be dropped by relying on L<Coro::AnyEvent> |
815 | L<Coro::AnyEvent>, which allows you to do a blocking C<< ->recv >> from |
823 | , which allows you to do a blocking C<< ->recv >> from any thread |
816 | any thread that doesn't run the event loop itself. |
824 | that doesn't run the event loop itself. L<Coro::AnyEvent> is loaded |
|
|
825 | automatically when L<Coro> is used with L<AnyEvent>, so code does not need |
|
|
826 | to do anything special to take advantage of that: any code that would |
|
|
827 | normally block your program because it calls C<recv>, be executed in an |
|
|
828 | C<async> thread instead without blocking other threads. |
817 | |
829 | |
818 | Not all event models support a blocking wait - some die in that case |
830 | Not all event models support a blocking wait - some die in that case |
819 | (programs might want to do that to stay interactive), so I<if you are |
831 | (programs might want to do that to stay interactive), so I<if you are |
820 | using this from a module, never require a blocking wait>. Instead, let the |
832 | using this from a module, never require a blocking wait>. Instead, let the |
821 | caller decide whether the call will block or not (for example, by coupling |
833 | caller decide whether the call will block or not (for example, by coupling |
… | |
… | |
1139 | a longer non-exhaustive list), and the list is heavily biased towards |
1151 | a longer non-exhaustive list), and the list is heavily biased towards |
1140 | modules of the AnyEvent author himself :) |
1152 | modules of the AnyEvent author himself :) |
1141 | |
1153 | |
1142 | =over 4 |
1154 | =over 4 |
1143 | |
1155 | |
1144 | =item L<AnyEvent::Util> |
1156 | =item L<AnyEvent::Util> (part of the AnyEvent distribution) |
1145 | |
1157 | |
1146 | Contains various utility functions that replace often-used blocking |
1158 | Contains various utility functions that replace often-used blocking |
1147 | functions such as C<inet_aton> with event/callback-based versions. |
1159 | functions such as C<inet_aton> with event/callback-based versions. |
1148 | |
1160 | |
1149 | =item L<AnyEvent::Socket> |
1161 | =item L<AnyEvent::Socket> (part of the AnyEvent distribution) |
1150 | |
1162 | |
1151 | Provides various utility functions for (internet protocol) sockets, |
1163 | Provides various utility functions for (internet protocol) sockets, |
1152 | addresses and name resolution. Also functions to create non-blocking tcp |
1164 | addresses and name resolution. Also functions to create non-blocking tcp |
1153 | connections or tcp servers, with IPv6 and SRV record support and more. |
1165 | connections or tcp servers, with IPv6 and SRV record support and more. |
1154 | |
1166 | |
1155 | =item L<AnyEvent::Handle> |
1167 | =item L<AnyEvent::Handle> (part of the AnyEvent distribution) |
1156 | |
1168 | |
1157 | Provide read and write buffers, manages watchers for reads and writes, |
1169 | Provide read and write buffers, manages watchers for reads and writes, |
1158 | supports raw and formatted I/O, I/O queued and fully transparent and |
1170 | supports raw and formatted I/O, I/O queued and fully transparent and |
1159 | non-blocking SSL/TLS (via L<AnyEvent::TLS>). |
1171 | non-blocking SSL/TLS (via L<AnyEvent::TLS>). |
1160 | |
1172 | |
1161 | =item L<AnyEvent::DNS> |
1173 | =item L<AnyEvent::DNS> (part of the AnyEvent distribution) |
1162 | |
1174 | |
1163 | Provides rich asynchronous DNS resolver capabilities. |
1175 | Provides rich asynchronous DNS resolver capabilities. |
1164 | |
1176 | |
1165 | =item L<AnyEvent::HTTP>, L<AnyEvent::IRC>, L<AnyEvent::XMPP>, L<AnyEvent::GPSD>, L<AnyEvent::IGS>, L<AnyEvent::FCP> |
1177 | =item L<AnyEvent::HTTP>, L<AnyEvent::IRC>, L<AnyEvent::XMPP>, L<AnyEvent::GPSD>, L<AnyEvent::IGS>, L<AnyEvent::FCP> |
1166 | |
1178 | |
1167 | Implement event-based interfaces to the protocols of the same name (for |
1179 | Implement event-based interfaces to the protocols of the same name (for |
1168 | the curious, IGS is the International Go Server and FCP is the Freenet |
1180 | the curious, IGS is the International Go Server and FCP is the Freenet |
1169 | Client Protocol). |
1181 | Client Protocol). |
1170 | |
1182 | |
1171 | =item L<AnyEvent::AIO> |
1183 | =item L<AnyEvent::AIO> (part of the AnyEvent distribution) |
1172 | |
1184 | |
1173 | Truly asynchronous (as opposed to non-blocking) I/O, should be in the |
1185 | Truly asynchronous (as opposed to non-blocking) I/O, should be in the |
1174 | toolbox of every event programmer. AnyEvent::AIO transparently fuses |
1186 | toolbox of every event programmer. AnyEvent::AIO transparently fuses |
1175 | L<IO::AIO> and AnyEvent together, giving AnyEvent access to event-based |
1187 | L<IO::AIO> and AnyEvent together, giving AnyEvent access to event-based |
1176 | file I/O, and much more. |
1188 | file I/O, and much more. |
|
|
1189 | |
|
|
1190 | =item L<AnyEvent::Fork>, L<AnyEvent::Fork::RPC>, L<AnyEvent::Fork::Pool>, L<AnyEvent::Fork::Remote> |
|
|
1191 | |
|
|
1192 | These let you safely fork new subprocesses, either locally or |
|
|
1193 | remotely (e.g.v ia ssh), using some RPC protocol or not, without |
|
|
1194 | the limitations normally imposed by fork (AnyEvent works fine for |
|
|
1195 | example). Dynamically-resized worker pools are obviously included as well. |
|
|
1196 | |
|
|
1197 | And they are quite tiny and fast as well - "abusing" L<AnyEvent::Fork> |
|
|
1198 | just to exec external programs can easily beat using C<fork> and C<exec> |
|
|
1199 | (or even C<system>) in most programs. |
1177 | |
1200 | |
1178 | =item L<AnyEvent::Filesys::Notify> |
1201 | =item L<AnyEvent::Filesys::Notify> |
1179 | |
1202 | |
1180 | AnyEvent is good for non-blocking stuff, but it can't detect file or |
1203 | AnyEvent is good for non-blocking stuff, but it can't detect file or |
1181 | path changes (e.g. "watch this directory for new files", "watch this |
1204 | path changes (e.g. "watch this directory for new files", "watch this |
… | |
… | |
1183 | do just that in a portbale fashion, supporting inotify on GNU/Linux and |
1206 | do just that in a portbale fashion, supporting inotify on GNU/Linux and |
1184 | some weird, without doubt broken, stuff on OS X to monitor files. It can |
1207 | some weird, without doubt broken, stuff on OS X to monitor files. It can |
1185 | fall back to blocking scans at regular intervals transparently on other |
1208 | fall back to blocking scans at regular intervals transparently on other |
1186 | platforms, so it's about as portable as it gets. |
1209 | platforms, so it's about as portable as it gets. |
1187 | |
1210 | |
1188 | (I haven't used it myself, but I haven't heard anybody complaining about |
1211 | (I haven't used it myself, but it seems the biggest problem with it is |
1189 | it yet). |
1212 | it quite bad performance). |
1190 | |
1213 | |
1191 | =item L<AnyEvent::DBI> |
1214 | =item L<AnyEvent::DBI> |
1192 | |
1215 | |
1193 | Executes L<DBI> requests asynchronously in a proxy process for you, |
1216 | Executes L<DBI> requests asynchronously in a proxy process for you, |
1194 | notifying you in an event-based way when the operation is finished. |
1217 | notifying you in an event-based way when the operation is finished. |
1195 | |
|
|
1196 | =item L<AnyEvent::HTTPD> |
|
|
1197 | |
|
|
1198 | A simple embedded webserver. |
|
|
1199 | |
1218 | |
1200 | =item L<AnyEvent::FastPing> |
1219 | =item L<AnyEvent::FastPing> |
1201 | |
1220 | |
1202 | The fastest ping in the west. |
1221 | The fastest ping in the west. |
1203 | |
1222 | |
… | |
… | |
1221 | |
1240 | |
1222 | =cut |
1241 | =cut |
1223 | |
1242 | |
1224 | package AnyEvent; |
1243 | package AnyEvent; |
1225 | |
1244 | |
1226 | # basically a tuned-down version of common::sense |
1245 | BEGIN { |
1227 | sub common_sense { |
1246 | require "AnyEvent/constants.pl"; |
1228 | # from common:.sense 3.5 |
1247 | &AnyEvent::common_sense; |
1229 | local $^W; |
|
|
1230 | ${^WARNING_BITS} ^= ${^WARNING_BITS} ^ "\x3c\x3f\x33\x00\x0f\xf0\x0f\xc0\xf0\xfc\x33\x00"; |
|
|
1231 | # use strict vars subs - NO UTF-8, as Util.pm doesn't like this atm. (uts46data.pl) |
|
|
1232 | $^H |= 0x00000600; |
|
|
1233 | } |
1248 | } |
1234 | |
|
|
1235 | BEGIN { AnyEvent::common_sense } |
|
|
1236 | |
1249 | |
1237 | use Carp (); |
1250 | use Carp (); |
1238 | |
1251 | |
1239 | our $VERSION = '7.03'; |
1252 | our $VERSION = '7.05'; |
1240 | our $MODEL; |
1253 | our $MODEL; |
1241 | our @ISA; |
1254 | our @ISA; |
1242 | our @REGISTRY; |
1255 | our @REGISTRY; |
1243 | our $VERBOSE; |
1256 | our $VERBOSE; |
1244 | our %PROTOCOL; # (ipv4|ipv6) => (1|2), higher numbers are preferred |
1257 | our %PROTOCOL; # (ipv4|ipv6) => (1|2), higher numbers are preferred |
1245 | our $MAX_SIGNAL_LATENCY = $ENV{PERL_ANYEVENT_MAX_SIGNAL_LATENCY} || 10; # executes after the BEGIN block below (tainting!) |
1258 | our $MAX_SIGNAL_LATENCY = $ENV{PERL_ANYEVENT_MAX_SIGNAL_LATENCY} || 10; # executes after the BEGIN block below (tainting!) |
1246 | |
1259 | |
1247 | BEGIN { |
1260 | BEGIN { |
1248 | require "AnyEvent/constants.pl"; |
|
|
1249 | |
|
|
1250 | eval "sub TAINT (){" . (${^TAINT}*1) . "}"; |
1261 | eval "sub TAINT (){" . (${^TAINT}*1) . "}"; |
1251 | |
1262 | |
1252 | delete @ENV{grep /^PERL_ANYEVENT_/, keys %ENV} |
1263 | delete @ENV{grep /^PERL_ANYEVENT_/, keys %ENV} |
1253 | if ${^TAINT}; |
1264 | if ${^TAINT}; |
1254 | |
1265 | |
… | |
… | |
2921 | This module is part of perl since release 5.008. It will be used when the |
2932 | This module is part of perl since release 5.008. It will be used when the |
2922 | chosen event library does not come with a timing source of its own. The |
2933 | chosen event library does not come with a timing source of its own. The |
2923 | pure-perl event loop (L<AnyEvent::Loop>) will additionally load it to |
2934 | pure-perl event loop (L<AnyEvent::Loop>) will additionally load it to |
2924 | try to use a monotonic clock for timing stability. |
2935 | try to use a monotonic clock for timing stability. |
2925 | |
2936 | |
|
|
2937 | =item L<AnyEvent::AIO> (and L<IO::AIO>) |
|
|
2938 | |
|
|
2939 | The default implementation of L<AnyEvent::IO> is to do I/O synchronously, |
|
|
2940 | stopping programs while they access the disk, which is fine for a lot of |
|
|
2941 | programs. |
|
|
2942 | |
|
|
2943 | Installing AnyEvent::AIO (and its IO::AIO dependency) makes it switch to |
|
|
2944 | a true asynchronous implementation, so event processing can continue even |
|
|
2945 | while waiting for disk I/O. |
|
|
2946 | |
2926 | =back |
2947 | =back |
2927 | |
2948 | |
2928 | |
2949 | |
2929 | =head1 FORK |
2950 | =head1 FORK |
2930 | |
2951 | |
… | |
… | |
2941 | usually happens when the first AnyEvent watcher is created, or the library |
2962 | usually happens when the first AnyEvent watcher is created, or the library |
2942 | is loaded). |
2963 | is loaded). |
2943 | |
2964 | |
2944 | If you have to fork, you must either do so I<before> creating your first |
2965 | If you have to fork, you must either do so I<before> creating your first |
2945 | watcher OR you must not use AnyEvent at all in the child OR you must do |
2966 | watcher OR you must not use AnyEvent at all in the child OR you must do |
2946 | something completely out of the scope of AnyEvent. |
2967 | something completely out of the scope of AnyEvent (see below). |
2947 | |
2968 | |
2948 | The problem of doing event processing in the parent I<and> the child |
2969 | The problem of doing event processing in the parent I<and> the child |
2949 | is much more complicated: even for backends that I<are> fork-aware or |
2970 | is much more complicated: even for backends that I<are> fork-aware or |
2950 | fork-safe, their behaviour is not usually what you want: fork clones all |
2971 | fork-safe, their behaviour is not usually what you want: fork clones all |
2951 | watchers, that means all timers, I/O watchers etc. are active in both |
2972 | watchers, that means all timers, I/O watchers etc. are active in both |
2952 | parent and child, which is almost never what you want. USing C<exec> |
2973 | parent and child, which is almost never what you want. Using C<exec> |
2953 | to start worker children from some kind of manage rprocess is usually |
2974 | to start worker children from some kind of manage prrocess is usually |
2954 | preferred, because it is much easier and cleaner, at the expense of having |
2975 | preferred, because it is much easier and cleaner, at the expense of having |
2955 | to have another binary. |
2976 | to have another binary. |
|
|
2977 | |
|
|
2978 | In addition to logical problems with fork, there are also implementation |
|
|
2979 | problems. For example, on POSIX systems, you cannot fork at all in Perl |
|
|
2980 | code if a thread (I am talking of pthreads here) was ever created in the |
|
|
2981 | process, and this is just the tip of the iceberg. In general, using fork |
|
|
2982 | from Perl is difficult, and attempting to use fork without an exec to |
|
|
2983 | implement some kind of parallel processing is almost certainly doomed. |
|
|
2984 | |
|
|
2985 | To safely fork and exec, you should use a module such as |
|
|
2986 | L<Proc::FastSpawn> that let's you safely fork and exec new processes. |
|
|
2987 | |
|
|
2988 | If you want to do multiprocessing using processes, you can |
|
|
2989 | look at the L<AnyEvent::Fork> module (and some related modules |
|
|
2990 | such as L<AnyEvent::Fork::RPC>, L<AnyEvent::Fork::Pool> and |
|
|
2991 | L<AnyEvent::Fork::Remote>). This module allows you to safely create |
|
|
2992 | subprocesses without any limitations - you can use X11 toolkits or |
|
|
2993 | AnyEvent in the children created by L<AnyEvent::Fork> safely and without |
|
|
2994 | any special precautions. |
2956 | |
2995 | |
2957 | |
2996 | |
2958 | =head1 SECURITY CONSIDERATIONS |
2997 | =head1 SECURITY CONSIDERATIONS |
2959 | |
2998 | |
2960 | AnyEvent can be forced to load any event model via |
2999 | AnyEvent can be forced to load any event model via |