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

Comparing AnyEvent/lib/AnyEvent.pm (file contents):
Revision 1.67 by root, Fri Apr 25 06:58:38 2008 UTC vs.
Revision 1.242 by root, Fri Jul 17 22:05:12 2009 UTC

1=head1 NAME 1=head1 NAME
2 2
3AnyEvent - provide framework for multiple event loops 3AnyEvent - provide framework for multiple event loops
4 4
5EV, Event, Coro::EV, Coro::Event, Glib, Tk, Perl, Event::Lib, Qt, POE - various supported event loops 5EV, Event, Glib, Tk, Perl, Event::Lib, Qt and POE are various supported
6event loops.
6 7
7=head1 SYNOPSIS 8=head1 SYNOPSIS
8 9
9 use AnyEvent; 10 use AnyEvent;
10 11
12 # file descriptor readable
11 my $w = AnyEvent->io (fh => $fh, poll => "r|w", cb => sub { 13 my $w = AnyEvent->io (fh => $fh, poll => "r", cb => sub { ... });
14
15 # one-shot or repeating timers
16 my $w = AnyEvent->timer (after => $seconds, cb => sub { ... });
17 my $w = AnyEvent->timer (after => $seconds, interval => $seconds, cb => ...
18
19 print AnyEvent->now; # prints current event loop time
20 print AnyEvent->time; # think Time::HiRes::time or simply CORE::time.
21
22 # POSIX signal
23 my $w = AnyEvent->signal (signal => "TERM", cb => sub { ... });
24
25 # child process exit
26 my $w = AnyEvent->child (pid => $pid, cb => sub {
27 my ($pid, $status) = @_;
12 ... 28 ...
13 }); 29 });
14 30
15 my $w = AnyEvent->timer (after => $seconds, cb => sub { 31 # called when event loop idle (if applicable)
16 ... 32 my $w = AnyEvent->idle (cb => sub { ... });
17 });
18 33
19 my $w = AnyEvent->condvar; # stores whether a condition was flagged 34 my $w = AnyEvent->condvar; # stores whether a condition was flagged
35 $w->send; # wake up current and all future recv's
20 $w->wait; # enters "main loop" till $condvar gets ->broadcast 36 $w->recv; # enters "main loop" till $condvar gets ->send
21 $w->broadcast; # wake up current and all future wait's 37 # use a condvar in callback mode:
38 $w->cb (sub { $_[0]->recv });
39
40=head1 INTRODUCTION/TUTORIAL
41
42This manpage is mainly a reference manual. If you are interested
43in a tutorial or some gentle introduction, have a look at the
44L<AnyEvent::Intro> manpage.
22 45
23=head1 WHY YOU SHOULD USE THIS MODULE (OR NOT) 46=head1 WHY YOU SHOULD USE THIS MODULE (OR NOT)
24 47
25Glib, POE, IO::Async, Event... CPAN offers event models by the dozen 48Glib, POE, IO::Async, Event... CPAN offers event models by the dozen
26nowadays. So what is different about AnyEvent? 49nowadays. So what is different about AnyEvent?
27 50
28Executive Summary: AnyEvent is I<compatible>, AnyEvent is I<free of 51Executive Summary: AnyEvent is I<compatible>, AnyEvent is I<free of
29policy> and AnyEvent is I<small and efficient>. 52policy> and AnyEvent is I<small and efficient>.
30 53
31First and foremost, I<AnyEvent is not an event model> itself, it only 54First and foremost, I<AnyEvent is not an event model> itself, it only
32interfaces to whatever event model the main program happens to use in a 55interfaces to whatever event model the main program happens to use, in a
33pragmatic way. For event models and certain classes of immortals alike, 56pragmatic way. For event models and certain classes of immortals alike,
34the statement "there can only be one" is a bitter reality: In general, 57the statement "there can only be one" is a bitter reality: In general,
35only one event loop can be active at the same time in a process. AnyEvent 58only one event loop can be active at the same time in a process. AnyEvent
36helps hiding the differences between those event loops. 59cannot change this, but it can hide the differences between those event
60loops.
37 61
38The goal of AnyEvent is to offer module authors the ability to do event 62The goal of AnyEvent is to offer module authors the ability to do event
39programming (waiting for I/O or timer events) without subscribing to a 63programming (waiting for I/O or timer events) without subscribing to a
40religion, a way of living, and most importantly: without forcing your 64religion, a way of living, and most importantly: without forcing your
41module users into the same thing by forcing them to use the same event 65module users into the same thing by forcing them to use the same event
42model you use. 66model you use.
43 67
44For modules like POE or IO::Async (which is a total misnomer as it is 68For modules like POE or IO::Async (which is a total misnomer as it is
45actually doing all I/O I<synchronously>...), using them in your module is 69actually doing all I/O I<synchronously>...), using them in your module is
46like joining a cult: After you joined, you are dependent on them and you 70like joining a cult: After you joined, you are dependent on them and you
47cannot use anything else, as it is simply incompatible to everything that 71cannot use anything else, as they are simply incompatible to everything
48isn't itself. What's worse, all the potential users of your module are 72that isn't them. What's worse, all the potential users of your
49I<also> forced to use the same event loop you use. 73module are I<also> forced to use the same event loop you use.
50 74
51AnyEvent is different: AnyEvent + POE works fine. AnyEvent + Glib works 75AnyEvent is different: AnyEvent + POE works fine. AnyEvent + Glib works
52fine. AnyEvent + Tk works fine etc. etc. but none of these work together 76fine. AnyEvent + Tk works fine etc. etc. but none of these work together
53with the rest: POE + IO::Async? no go. Tk + Event? no go. Again: if 77with the rest: POE + IO::Async? No go. Tk + Event? No go. Again: if
54your module uses one of those, every user of your module has to use it, 78your module uses one of those, every user of your module has to use it,
55too. But if your module uses AnyEvent, it works transparently with all 79too. But if your module uses AnyEvent, it works transparently with all
56event models it supports (including stuff like POE and IO::Async, as long 80event models it supports (including stuff like IO::Async, as long as those
57as those use one of the supported event loops. It is trivial to add new 81use one of the supported event loops. It is trivial to add new event loops
58event loops to AnyEvent, too, so it is future-proof). 82to AnyEvent, too, so it is future-proof).
59 83
60In addition to being free of having to use I<the one and only true event 84In addition to being free of having to use I<the one and only true event
61model>, AnyEvent also is free of bloat and policy: with POE or similar 85model>, AnyEvent also is free of bloat and policy: with POE or similar
62modules, you get an enourmous amount of code and strict rules you have to 86modules, you get an enormous amount of code and strict rules you have to
63follow. AnyEvent, on the other hand, is lean and up to the point, by only 87follow. AnyEvent, on the other hand, is lean and up to the point, by only
64offering the functionality that is necessary, in as thin as a wrapper as 88offering the functionality that is necessary, in as thin as a wrapper as
65technically possible. 89technically possible.
66 90
91Of course, AnyEvent comes with a big (and fully optional!) toolbox
92of useful functionality, such as an asynchronous DNS resolver, 100%
93non-blocking connects (even with TLS/SSL, IPv6 and on broken platforms
94such as Windows) and lots of real-world knowledge and workarounds for
95platform bugs and differences.
96
67Of course, if you want lots of policy (this can arguably be somewhat 97Now, if you I<do want> lots of policy (this can arguably be somewhat
68useful) and you want to force your users to use the one and only event 98useful) and you want to force your users to use the one and only event
69model, you should I<not> use this module. 99model, you should I<not> use this module.
70
71 100
72=head1 DESCRIPTION 101=head1 DESCRIPTION
73 102
74L<AnyEvent> provides an identical interface to multiple event loops. This 103L<AnyEvent> provides an identical interface to multiple event loops. This
75allows module authors to utilise an event loop without forcing module 104allows module authors to utilise an event loop without forcing module
79The interface itself is vaguely similar, but not identical to the L<Event> 108The interface itself is vaguely similar, but not identical to the L<Event>
80module. 109module.
81 110
82During the first call of any watcher-creation method, the module tries 111During the first call of any watcher-creation method, the module tries
83to detect the currently loaded event loop by probing whether one of the 112to detect the currently loaded event loop by probing whether one of the
84following modules is already loaded: L<Coro::EV>, L<Coro::Event>, L<EV>, 113following modules is already loaded: L<EV>,
85L<Event>, L<Glib>, L<Tk>, L<AnyEvent::Impl::Perl>, L<Event::Lib>, L<Qt>, 114L<Event>, L<Glib>, L<AnyEvent::Impl::Perl>, L<Tk>, L<Event::Lib>, L<Qt>,
86L<POE>. The first one found is used. If none are found, the module tries 115L<POE>. The first one found is used. If none are found, the module tries
87to load these modules (excluding Event::Lib, Qt and POE as the pure perl 116to load these modules (excluding Tk, Event::Lib, Qt and POE as the pure perl
88adaptor should always succeed) in the order given. The first one that can 117adaptor should always succeed) in the order given. The first one that can
89be successfully loaded will be used. If, after this, still none could be 118be successfully loaded will be used. If, after this, still none could be
90found, AnyEvent will fall back to a pure-perl event loop, which is not 119found, AnyEvent will fall back to a pure-perl event loop, which is not
91very efficient, but should work everywhere. 120very efficient, but should work everywhere.
92 121
103starts using it, all bets are off. Maybe you should tell their authors to 132starts using it, all bets are off. Maybe you should tell their authors to
104use AnyEvent so their modules work together with others seamlessly... 133use AnyEvent so their modules work together with others seamlessly...
105 134
106The pure-perl implementation of AnyEvent is called 135The pure-perl implementation of AnyEvent is called
107C<AnyEvent::Impl::Perl>. Like other event modules you can load it 136C<AnyEvent::Impl::Perl>. Like other event modules you can load it
108explicitly. 137explicitly and enjoy the high availability of that event loop :)
109 138
110=head1 WATCHERS 139=head1 WATCHERS
111 140
112AnyEvent has the central concept of a I<watcher>, which is an object that 141AnyEvent has the central concept of a I<watcher>, which is an object that
113stores relevant data for each kind of event you are waiting for, such as 142stores relevant data for each kind of event you are waiting for, such as
114the callback to call, the filehandle to watch, etc. 143the callback to call, the file handle to watch, etc.
115 144
116These watchers are normal Perl objects with normal Perl lifetime. After 145These watchers are normal Perl objects with normal Perl lifetime. After
117creating a watcher it will immediately "watch" for events and invoke the 146creating a watcher it will immediately "watch" for events and invoke the
118callback when the event occurs (of course, only when the event model 147callback when the event occurs (of course, only when the event model
119is in control). 148is in control).
120 149
150Note that B<callbacks must not permanently change global variables>
151potentially in use by the event loop (such as C<$_> or C<$[>) and that B<<
152callbacks must not C<die> >>. The former is good programming practise in
153Perl and the latter stems from the fact that exception handling differs
154widely between event loops.
155
121To disable the watcher you have to destroy it (e.g. by setting the 156To disable the watcher you have to destroy it (e.g. by setting the
122variable you store it in to C<undef> or otherwise deleting all references 157variable you store it in to C<undef> or otherwise deleting all references
123to it). 158to it).
124 159
125All watchers are created by calling a method on the C<AnyEvent> class. 160All watchers are created by calling a method on the C<AnyEvent> class.
127Many watchers either are used with "recursion" (repeating timers for 162Many watchers either are used with "recursion" (repeating timers for
128example), or need to refer to their watcher object in other ways. 163example), or need to refer to their watcher object in other ways.
129 164
130An any way to achieve that is this pattern: 165An any way to achieve that is this pattern:
131 166
132 my $w; $w = AnyEvent->type (arg => value ..., cb => sub { 167 my $w; $w = AnyEvent->type (arg => value ..., cb => sub {
133 # you can use $w here, for example to undef it 168 # you can use $w here, for example to undef it
134 undef $w; 169 undef $w;
135 }); 170 });
136 171
137Note that C<my $w; $w => combination. This is necessary because in Perl, 172Note that C<my $w; $w => combination. This is necessary because in Perl,
138my variables are only visible after the statement in which they are 173my variables are only visible after the statement in which they are
139declared. 174declared.
140 175
141=head2 IO WATCHERS 176=head2 I/O WATCHERS
142 177
143You can create an I/O watcher by calling the C<< AnyEvent->io >> method 178You can create an I/O watcher by calling the C<< AnyEvent->io >> method
144with the following mandatory key-value pairs as arguments: 179with the following mandatory key-value pairs as arguments:
145 180
146C<fh> the Perl I<file handle> (I<not> file descriptor) to watch for 181C<fh> is the Perl I<file handle> (or a naked file descriptor) to watch
182for events (AnyEvent might or might not keep a reference to this file
183handle). Note that only file handles pointing to things for which
184non-blocking operation makes sense are allowed. This includes sockets,
185most character devices, pipes, fifos and so on, but not for example files
186or block devices.
187
147events. C<poll> must be a string that is either C<r> or C<w>, which 188C<poll> must be a string that is either C<r> or C<w>, which creates a
148creates a watcher waiting for "r"eadable or "w"ritable events, 189watcher waiting for "r"eadable or "w"ritable events, respectively.
190
149respectively. C<cb> is the callback to invoke each time the file handle 191C<cb> is the callback to invoke each time the file handle becomes ready.
150becomes ready.
151 192
152As long as the I/O watcher exists it will keep the file descriptor or a 193Although the callback might get passed parameters, their value and
153copy of it alive/open. 194presence is undefined and you cannot rely on them. Portable AnyEvent
195callbacks cannot use arguments passed to I/O watcher callbacks.
154 196
197The I/O watcher might use the underlying file descriptor or a copy of it.
155It is not allowed to close a file handle as long as any watcher is active 198You must not close a file handle as long as any watcher is active on the
156on the underlying file descriptor. 199underlying file descriptor.
157 200
158Some event loops issue spurious readyness notifications, so you should 201Some event loops issue spurious readyness notifications, so you should
159always use non-blocking calls when reading/writing from/to your file 202always use non-blocking calls when reading/writing from/to your file
160handles. 203handles.
161 204
162Example:
163
164 # wait for readability of STDIN, then read a line and disable the watcher 205Example: wait for readability of STDIN, then read a line and disable the
206watcher.
207
165 my $w; $w = AnyEvent->io (fh => \*STDIN, poll => 'r', cb => sub { 208 my $w; $w = AnyEvent->io (fh => \*STDIN, poll => 'r', cb => sub {
166 chomp (my $input = <STDIN>); 209 chomp (my $input = <STDIN>);
167 warn "read: $input\n"; 210 warn "read: $input\n";
168 undef $w; 211 undef $w;
169 }); 212 });
172 215
173You can create a time watcher by calling the C<< AnyEvent->timer >> 216You can create a time watcher by calling the C<< AnyEvent->timer >>
174method with the following mandatory arguments: 217method with the following mandatory arguments:
175 218
176C<after> specifies after how many seconds (fractional values are 219C<after> specifies after how many seconds (fractional values are
177supported) should the timer activate. C<cb> the callback to invoke in that 220supported) the callback should be invoked. C<cb> is the callback to invoke
178case. 221in that case.
179 222
180The timer callback will be invoked at most once: if you want a repeating 223Although the callback might get passed parameters, their value and
181timer you have to create a new watcher (this is a limitation by both Tk 224presence is undefined and you cannot rely on them. Portable AnyEvent
182and Glib). 225callbacks cannot use arguments passed to time watcher callbacks.
183 226
184Example: 227The callback will normally be invoked once only. If you specify another
228parameter, C<interval>, as a strictly positive number (> 0), then the
229callback will be invoked regularly at that interval (in fractional
230seconds) after the first invocation. If C<interval> is specified with a
231false value, then it is treated as if it were missing.
185 232
233The callback will be rescheduled before invoking the callback, but no
234attempt is done to avoid timer drift in most backends, so the interval is
235only approximate.
236
186 # fire an event after 7.7 seconds 237Example: fire an event after 7.7 seconds.
238
187 my $w = AnyEvent->timer (after => 7.7, cb => sub { 239 my $w = AnyEvent->timer (after => 7.7, cb => sub {
188 warn "timeout\n"; 240 warn "timeout\n";
189 }); 241 });
190 242
191 # to cancel the timer: 243 # to cancel the timer:
192 undef $w; 244 undef $w;
193 245
194Example 2:
195
196 # fire an event after 0.5 seconds, then roughly every second 246Example 2: fire an event after 0.5 seconds, then roughly every second.
197 my $w;
198 247
199 my $cb = sub {
200 # cancel the old timer while creating a new one
201 $w = AnyEvent->timer (after => 1, cb => $cb); 248 my $w = AnyEvent->timer (after => 0.5, interval => 1, cb => sub {
249 warn "timeout\n";
202 }; 250 };
203
204 # start the "loop" by creating the first watcher
205 $w = AnyEvent->timer (after => 0.5, cb => $cb);
206 251
207=head3 TIMING ISSUES 252=head3 TIMING ISSUES
208 253
209There are two ways to handle timers: based on real time (relative, "fire 254There are two ways to handle timers: based on real time (relative, "fire
210in 10 seconds") and based on wallclock time (absolute, "fire at 12 255in 10 seconds") and based on wallclock time (absolute, "fire at 12
222timers. 267timers.
223 268
224AnyEvent always prefers relative timers, if available, matching the 269AnyEvent always prefers relative timers, if available, matching the
225AnyEvent API. 270AnyEvent API.
226 271
272AnyEvent has two additional methods that return the "current time":
273
274=over 4
275
276=item AnyEvent->time
277
278This returns the "current wallclock time" as a fractional number of
279seconds since the Epoch (the same thing as C<time> or C<Time::HiRes::time>
280return, and the result is guaranteed to be compatible with those).
281
282It progresses independently of any event loop processing, i.e. each call
283will check the system clock, which usually gets updated frequently.
284
285=item AnyEvent->now
286
287This also returns the "current wallclock time", but unlike C<time>, above,
288this value might change only once per event loop iteration, depending on
289the event loop (most return the same time as C<time>, above). This is the
290time that AnyEvent's timers get scheduled against.
291
292I<In almost all cases (in all cases if you don't care), this is the
293function to call when you want to know the current time.>
294
295This function is also often faster then C<< AnyEvent->time >>, and
296thus the preferred method if you want some timestamp (for example,
297L<AnyEvent::Handle> uses this to update it's activity timeouts).
298
299The rest of this section is only of relevance if you try to be very exact
300with your timing, you can skip it without bad conscience.
301
302For a practical example of when these times differ, consider L<Event::Lib>
303and L<EV> and the following set-up:
304
305The event loop is running and has just invoked one of your callback at
306time=500 (assume no other callbacks delay processing). In your callback,
307you wait a second by executing C<sleep 1> (blocking the process for a
308second) and then (at time=501) you create a relative timer that fires
309after three seconds.
310
311With L<Event::Lib>, C<< AnyEvent->time >> and C<< AnyEvent->now >> will
312both return C<501>, because that is the current time, and the timer will
313be scheduled to fire at time=504 (C<501> + C<3>).
314
315With L<EV>, C<< AnyEvent->time >> returns C<501> (as that is the current
316time), but C<< AnyEvent->now >> returns C<500>, as that is the time the
317last event processing phase started. With L<EV>, your timer gets scheduled
318to run at time=503 (C<500> + C<3>).
319
320In one sense, L<Event::Lib> is more exact, as it uses the current time
321regardless of any delays introduced by event processing. However, most
322callbacks do not expect large delays in processing, so this causes a
323higher drift (and a lot more system calls to get the current time).
324
325In another sense, L<EV> is more exact, as your timer will be scheduled at
326the same time, regardless of how long event processing actually took.
327
328In either case, if you care (and in most cases, you don't), then you
329can get whatever behaviour you want with any event loop, by taking the
330difference between C<< AnyEvent->time >> and C<< AnyEvent->now >> into
331account.
332
333=item AnyEvent->now_update
334
335Some event loops (such as L<EV> or L<AnyEvent::Impl::Perl>) cache
336the current time for each loop iteration (see the discussion of L<<
337AnyEvent->now >>, above).
338
339When a callback runs for a long time (or when the process sleeps), then
340this "current" time will differ substantially from the real time, which
341might affect timers and time-outs.
342
343When this is the case, you can call this method, which will update the
344event loop's idea of "current time".
345
346Note that updating the time I<might> cause some events to be handled.
347
348=back
349
227=head2 SIGNAL WATCHERS 350=head2 SIGNAL WATCHERS
228 351
229You can watch for signals using a signal watcher, C<signal> is the signal 352You can watch for signals using a signal watcher, C<signal> is the signal
230I<name> without any C<SIG> prefix, C<cb> is the Perl callback to 353I<name> in uppercase and without any C<SIG> prefix, C<cb> is the Perl
231be invoked whenever a signal occurs. 354callback to be invoked whenever a signal occurs.
232 355
356Although the callback might get passed parameters, their value and
357presence is undefined and you cannot rely on them. Portable AnyEvent
358callbacks cannot use arguments passed to signal watcher callbacks.
359
233Multiple signal occurances can be clumped together into one callback 360Multiple signal occurrences can be clumped together into one callback
234invocation, and callback invocation will be synchronous. synchronous means 361invocation, and callback invocation will be synchronous. Synchronous means
235that it might take a while until the signal gets handled by the process, 362that it might take a while until the signal gets handled by the process,
236but it is guarenteed not to interrupt any other callbacks. 363but it is guaranteed not to interrupt any other callbacks.
237 364
238The main advantage of using these watchers is that you can share a signal 365The main advantage of using these watchers is that you can share a signal
239between multiple watchers. 366between multiple watchers, and AnyEvent will ensure that signals will not
367interrupt your program at bad times.
240 368
241This watcher might use C<%SIG>, so programs overwriting those signals 369This watcher might use C<%SIG> (depending on the event loop used),
242directly will likely not work correctly. 370so programs overwriting those signals directly will likely not work
371correctly.
372
373Also note that many event loops (e.g. Glib, Tk, Qt, IO::Async) do not
374support attaching callbacks to signals, which is a pity, as you cannot do
375race-free signal handling in perl. AnyEvent will try to do it's best, but
376in some cases, signals will be delayed. The maximum time a signal might
377be delayed is specified in C<$AnyEvent::MAX_SIGNAL_LATENCY> (default: 10
378seconds). This variable can be changed only before the first signal
379watcher is created, and should be left alone otherwise. Higher values
380will cause fewer spurious wake-ups, which is better for power and CPU
381saving. All these problems can be avoided by installing the optional
382L<Async::Interrupt> module.
243 383
244Example: exit on SIGINT 384Example: exit on SIGINT
245 385
246 my $w = AnyEvent->signal (signal => "INT", cb => sub { exit 1 }); 386 my $w = AnyEvent->signal (signal => "INT", cb => sub { exit 1 });
247 387
248=head2 CHILD PROCESS WATCHERS 388=head2 CHILD PROCESS WATCHERS
249 389
250You can also watch on a child process exit and catch its exit status. 390You can also watch on a child process exit and catch its exit status.
251 391
252The child process is specified by the C<pid> argument (if set to C<0>, it 392The child process is specified by the C<pid> argument (if set to C<0>, it
253watches for any child process exit). The watcher will trigger as often 393watches for any child process exit). The watcher will triggered only when
254as status change for the child are received. This works by installing a 394the child process has finished and an exit status is available, not on
255signal handler for C<SIGCHLD>. The callback will be called with the pid 395any trace events (stopped/continued).
256and exit status (as returned by waitpid).
257 396
258Example: wait for pid 1333 397The callback will be called with the pid and exit status (as returned by
398waitpid), so unlike other watcher types, you I<can> rely on child watcher
399callback arguments.
259 400
401This watcher type works by installing a signal handler for C<SIGCHLD>,
402and since it cannot be shared, nothing else should use SIGCHLD or reap
403random child processes (waiting for specific child processes, e.g. inside
404C<system>, is just fine).
405
406There is a slight catch to child watchers, however: you usually start them
407I<after> the child process was created, and this means the process could
408have exited already (and no SIGCHLD will be sent anymore).
409
410Not all event models handle this correctly (neither POE nor IO::Async do,
411see their AnyEvent::Impl manpages for details), but even for event models
412that I<do> handle this correctly, they usually need to be loaded before
413the process exits (i.e. before you fork in the first place). AnyEvent's
414pure perl event loop handles all cases correctly regardless of when you
415start the watcher.
416
417This means you cannot create a child watcher as the very first
418thing in an AnyEvent program, you I<have> to create at least one
419watcher before you C<fork> the child (alternatively, you can call
420C<AnyEvent::detect>).
421
422As most event loops do not support waiting for child events, they will be
423emulated by AnyEvent in most cases, in which the latency and race problems
424mentioned in the description of signal watchers apply.
425
426Example: fork a process and wait for it
427
428 my $done = AnyEvent->condvar;
429
430 my $pid = fork or exit 5;
431
260 my $w = AnyEvent->child ( 432 my $w = AnyEvent->child (
261 pid => 1333, 433 pid => $pid,
262 cb => sub { 434 cb => sub {
263 my ($pid, $status) = @_; 435 my ($pid, $status) = @_;
264 warn "pid $pid exited with status $status"; 436 warn "pid $pid exited with status $status";
437 $done->send;
265 }, 438 },
266 ); 439 );
440
441 # do something else, then wait for process exit
442 $done->recv;
443
444=head2 IDLE WATCHERS
445
446Sometimes there is a need to do something, but it is not so important
447to do it instantly, but only when there is nothing better to do. This
448"nothing better to do" is usually defined to be "no other events need
449attention by the event loop".
450
451Idle watchers ideally get invoked when the event loop has nothing
452better to do, just before it would block the process to wait for new
453events. Instead of blocking, the idle watcher is invoked.
454
455Most event loops unfortunately do not really support idle watchers (only
456EV, Event and Glib do it in a usable fashion) - for the rest, AnyEvent
457will simply call the callback "from time to time".
458
459Example: read lines from STDIN, but only process them when the
460program is otherwise idle:
461
462 my @lines; # read data
463 my $idle_w;
464 my $io_w = AnyEvent->io (fh => \*STDIN, poll => 'r', cb => sub {
465 push @lines, scalar <STDIN>;
466
467 # start an idle watcher, if not already done
468 $idle_w ||= AnyEvent->idle (cb => sub {
469 # handle only one line, when there are lines left
470 if (my $line = shift @lines) {
471 print "handled when idle: $line";
472 } else {
473 # otherwise disable the idle watcher again
474 undef $idle_w;
475 }
476 });
477 });
267 478
268=head2 CONDITION VARIABLES 479=head2 CONDITION VARIABLES
269 480
481If you are familiar with some event loops you will know that all of them
482require you to run some blocking "loop", "run" or similar function that
483will actively watch for new events and call your callbacks.
484
485AnyEvent is slightly different: it expects somebody else to run the event
486loop and will only block when necessary (usually when told by the user).
487
488The instrument to do that is called a "condition variable", so called
489because they represent a condition that must become true.
490
491Now is probably a good time to look at the examples further below.
492
270Condition variables can be created by calling the C<< AnyEvent->condvar >> 493Condition variables can be created by calling the C<< AnyEvent->condvar
271method without any arguments. 494>> method, usually without arguments. The only argument pair allowed is
495C<cb>, which specifies a callback to be called when the condition variable
496becomes true, with the condition variable as the first argument (but not
497the results).
272 498
273A condition variable waits for a condition - precisely that the C<< 499After creation, the condition variable is "false" until it becomes "true"
274->broadcast >> method has been called. 500by calling the C<send> method (or calling the condition variable as if it
501were a callback, read about the caveats in the description for the C<<
502->send >> method).
275 503
276They are very useful to signal that a condition has been fulfilled, for 504Condition variables are similar to callbacks, except that you can
505optionally wait for them. They can also be called merge points - points
506in time where multiple outstanding events have been processed. And yet
507another way to call them is transactions - each condition variable can be
508used to represent a transaction, which finishes at some point and delivers
509a result.
510
511Condition variables are very useful to signal that something has finished,
277example, if you write a module that does asynchronous http requests, 512for example, if you write a module that does asynchronous http requests,
278then a condition variable would be the ideal candidate to signal the 513then a condition variable would be the ideal candidate to signal the
279availability of results. 514availability of results. The user can either act when the callback is
515called or can synchronously C<< ->recv >> for the results.
280 516
281You can also use condition variables to block your main program until 517You can also use them to simulate traditional event loops - for example,
282an event occurs - for example, you could C<< ->wait >> in your main 518you can block your main program until an event occurs - for example, you
283program until the user clicks the Quit button in your app, which would C<< 519could C<< ->recv >> in your main program until the user clicks the Quit
284->broadcast >> the "quit" event. 520button of your app, which would C<< ->send >> the "quit" event.
285 521
286Note that condition variables recurse into the event loop - if you have 522Note that condition variables recurse into the event loop - if you have
287two pirces of code that call C<< ->wait >> in a round-robbin fashion, you 523two pieces of code that call C<< ->recv >> in a round-robin fashion, you
288lose. Therefore, condition variables are good to export to your caller, but 524lose. Therefore, condition variables are good to export to your caller, but
289you should avoid making a blocking wait yourself, at least in callbacks, 525you should avoid making a blocking wait yourself, at least in callbacks,
290as this asks for trouble. 526as this asks for trouble.
291 527
292This object has two methods: 528Condition variables are represented by hash refs in perl, and the keys
529used by AnyEvent itself are all named C<_ae_XXX> to make subclassing
530easy (it is often useful to build your own transaction class on top of
531AnyEvent). To subclass, use C<AnyEvent::CondVar> as base class and call
532it's C<new> method in your own C<new> method.
293 533
294=over 4 534There are two "sides" to a condition variable - the "producer side" which
535eventually calls C<< -> send >>, and the "consumer side", which waits
536for the send to occur.
295 537
296=item $cv->wait 538Example: wait for a timer.
297
298Wait (blocking if necessary) until the C<< ->broadcast >> method has been
299called on c<$cv>, while servicing other watchers normally.
300
301You can only wait once on a condition - additional calls will return
302immediately.
303
304Not all event models support a blocking wait - some die in that case
305(programs might want to do that to stay interactive), so I<if you are
306using this from a module, never require a blocking wait>, but let the
307caller decide whether the call will block or not (for example, by coupling
308condition variables with some kind of request results and supporting
309callbacks so the caller knows that getting the result will not block,
310while still suppporting blocking waits if the caller so desires).
311
312Another reason I<never> to C<< ->wait >> in a module is that you cannot
313sensibly have two C<< ->wait >>'s in parallel, as that would require
314multiple interpreters or coroutines/threads, none of which C<AnyEvent>
315can supply (the coroutine-aware backends L<AnyEvent::Impl::CoroEV> and
316L<AnyEvent::Impl::CoroEvent> explicitly support concurrent C<< ->wait >>'s
317from different coroutines, however).
318
319=item $cv->broadcast
320
321Flag the condition as ready - a running C<< ->wait >> and all further
322calls to C<wait> will (eventually) return after this method has been
323called. If nobody is waiting the broadcast will be remembered..
324
325=back
326
327Example:
328 539
329 # wait till the result is ready 540 # wait till the result is ready
330 my $result_ready = AnyEvent->condvar; 541 my $result_ready = AnyEvent->condvar;
331 542
332 # do something such as adding a timer 543 # do something such as adding a timer
333 # or socket watcher the calls $result_ready->broadcast 544 # or socket watcher the calls $result_ready->send
334 # when the "result" is ready. 545 # when the "result" is ready.
335 # in this case, we simply use a timer: 546 # in this case, we simply use a timer:
336 my $w = AnyEvent->timer ( 547 my $w = AnyEvent->timer (
337 after => 1, 548 after => 1,
338 cb => sub { $result_ready->broadcast }, 549 cb => sub { $result_ready->send },
339 ); 550 );
340 551
341 # this "blocks" (while handling events) till the watcher 552 # this "blocks" (while handling events) till the callback
342 # calls broadcast 553 # calls -<send
343 $result_ready->wait; 554 $result_ready->recv;
555
556Example: wait for a timer, but take advantage of the fact that condition
557variables are also callable directly.
558
559 my $done = AnyEvent->condvar;
560 my $delay = AnyEvent->timer (after => 5, cb => $done);
561 $done->recv;
562
563Example: Imagine an API that returns a condvar and doesn't support
564callbacks. This is how you make a synchronous call, for example from
565the main program:
566
567 use AnyEvent::CouchDB;
568
569 ...
570
571 my @info = $couchdb->info->recv;
572
573And this is how you would just set a callback to be called whenever the
574results are available:
575
576 $couchdb->info->cb (sub {
577 my @info = $_[0]->recv;
578 });
579
580=head3 METHODS FOR PRODUCERS
581
582These methods should only be used by the producing side, i.e. the
583code/module that eventually sends the signal. Note that it is also
584the producer side which creates the condvar in most cases, but it isn't
585uncommon for the consumer to create it as well.
586
587=over 4
588
589=item $cv->send (...)
590
591Flag the condition as ready - a running C<< ->recv >> and all further
592calls to C<recv> will (eventually) return after this method has been
593called. If nobody is waiting the send will be remembered.
594
595If a callback has been set on the condition variable, it is called
596immediately from within send.
597
598Any arguments passed to the C<send> call will be returned by all
599future C<< ->recv >> calls.
600
601Condition variables are overloaded so one can call them directly (as if
602they were a code reference). Calling them directly is the same as calling
603C<send>.
604
605=item $cv->croak ($error)
606
607Similar to send, but causes all call's to C<< ->recv >> to invoke
608C<Carp::croak> with the given error message/object/scalar.
609
610This can be used to signal any errors to the condition variable
611user/consumer. Doing it this way instead of calling C<croak> directly
612delays the error detetcion, but has the overwhelmign advantage that it
613diagnoses the error at the place where the result is expected, and not
614deep in some event clalback without connection to the actual code causing
615the problem.
616
617=item $cv->begin ([group callback])
618
619=item $cv->end
620
621These two methods can be used to combine many transactions/events into
622one. For example, a function that pings many hosts in parallel might want
623to use a condition variable for the whole process.
624
625Every call to C<< ->begin >> will increment a counter, and every call to
626C<< ->end >> will decrement it. If the counter reaches C<0> in C<< ->end
627>>, the (last) callback passed to C<begin> will be executed. That callback
628is I<supposed> to call C<< ->send >>, but that is not required. If no
629callback was set, C<send> will be called without any arguments.
630
631You can think of C<< $cv->send >> giving you an OR condition (one call
632sends), while C<< $cv->begin >> and C<< $cv->end >> giving you an AND
633condition (all C<begin> calls must be C<end>'ed before the condvar sends).
634
635Let's start with a simple example: you have two I/O watchers (for example,
636STDOUT and STDERR for a program), and you want to wait for both streams to
637close before activating a condvar:
638
639 my $cv = AnyEvent->condvar;
640
641 $cv->begin; # first watcher
642 my $w1 = AnyEvent->io (fh => $fh1, cb => sub {
643 defined sysread $fh1, my $buf, 4096
644 or $cv->end;
645 });
646
647 $cv->begin; # second watcher
648 my $w2 = AnyEvent->io (fh => $fh2, cb => sub {
649 defined sysread $fh2, my $buf, 4096
650 or $cv->end;
651 });
652
653 $cv->recv;
654
655This works because for every event source (EOF on file handle), there is
656one call to C<begin>, so the condvar waits for all calls to C<end> before
657sending.
658
659The ping example mentioned above is slightly more complicated, as the
660there are results to be passwd back, and the number of tasks that are
661begung can potentially be zero:
662
663 my $cv = AnyEvent->condvar;
664
665 my %result;
666 $cv->begin (sub { $cv->send (\%result) });
667
668 for my $host (@list_of_hosts) {
669 $cv->begin;
670 ping_host_then_call_callback $host, sub {
671 $result{$host} = ...;
672 $cv->end;
673 };
674 }
675
676 $cv->end;
677
678This code fragment supposedly pings a number of hosts and calls
679C<send> after results for all then have have been gathered - in any
680order. To achieve this, the code issues a call to C<begin> when it starts
681each ping request and calls C<end> when it has received some result for
682it. Since C<begin> and C<end> only maintain a counter, the order in which
683results arrive is not relevant.
684
685There is an additional bracketing call to C<begin> and C<end> outside the
686loop, which serves two important purposes: first, it sets the callback
687to be called once the counter reaches C<0>, and second, it ensures that
688C<send> is called even when C<no> hosts are being pinged (the loop
689doesn't execute once).
690
691This is the general pattern when you "fan out" into multiple (but
692potentially none) subrequests: use an outer C<begin>/C<end> pair to set
693the callback and ensure C<end> is called at least once, and then, for each
694subrequest you start, call C<begin> and for each subrequest you finish,
695call C<end>.
696
697=back
698
699=head3 METHODS FOR CONSUMERS
700
701These methods should only be used by the consuming side, i.e. the
702code awaits the condition.
703
704=over 4
705
706=item $cv->recv
707
708Wait (blocking if necessary) until the C<< ->send >> or C<< ->croak
709>> methods have been called on c<$cv>, while servicing other watchers
710normally.
711
712You can only wait once on a condition - additional calls are valid but
713will return immediately.
714
715If an error condition has been set by calling C<< ->croak >>, then this
716function will call C<croak>.
717
718In list context, all parameters passed to C<send> will be returned,
719in scalar context only the first one will be returned.
720
721Note that doing a blocking wait in a callback is not supported by any
722event loop, that is, recursive invocation of a blocking C<< ->recv
723>> is not allowed, and the C<recv> call will C<croak> if such a
724condition is detected. This condition can be slightly loosened by using
725L<Coro::AnyEvent>, which allows you to do a blocking C<< ->recv >> from
726any thread that doesn't run the event loop itself.
727
728Not all event models support a blocking wait - some die in that case
729(programs might want to do that to stay interactive), so I<if you are
730using this from a module, never require a blocking wait>. Instead, let the
731caller decide whether the call will block or not (for example, by coupling
732condition variables with some kind of request results and supporting
733callbacks so the caller knows that getting the result will not block,
734while still supporting blocking waits if the caller so desires).
735
736You can ensure that C<< -recv >> never blocks by setting a callback and
737only calling C<< ->recv >> from within that callback (or at a later
738time). This will work even when the event loop does not support blocking
739waits otherwise.
740
741=item $bool = $cv->ready
742
743Returns true when the condition is "true", i.e. whether C<send> or
744C<croak> have been called.
745
746=item $cb = $cv->cb ($cb->($cv))
747
748This is a mutator function that returns the callback set and optionally
749replaces it before doing so.
750
751The callback will be called when the condition becomes "true", i.e. when
752C<send> or C<croak> are called, with the only argument being the condition
753variable itself. Calling C<recv> inside the callback or at any later time
754is guaranteed not to block.
755
756=back
757
758=head1 SUPPORTED EVENT LOOPS/BACKENDS
759
760The available backend classes are (every class has its own manpage):
761
762=over 4
763
764=item Backends that are autoprobed when no other event loop can be found.
765
766EV is the preferred backend when no other event loop seems to be in
767use. If EV is not installed, then AnyEvent will try Event, and, failing
768that, will fall back to its own pure-perl implementation, which is
769available everywhere as it comes with AnyEvent itself.
770
771 AnyEvent::Impl::EV based on EV (interface to libev, best choice).
772 AnyEvent::Impl::Event based on Event, very stable, few glitches.
773 AnyEvent::Impl::Perl pure-perl implementation, fast and portable.
774
775=item Backends that are transparently being picked up when they are used.
776
777These will be used when they are currently loaded when the first watcher
778is created, in which case it is assumed that the application is using
779them. This means that AnyEvent will automatically pick the right backend
780when the main program loads an event module before anything starts to
781create watchers. Nothing special needs to be done by the main program.
782
783 AnyEvent::Impl::Glib based on Glib, slow but very stable.
784 AnyEvent::Impl::Tk based on Tk, very broken.
785 AnyEvent::Impl::EventLib based on Event::Lib, leaks memory and worse.
786 AnyEvent::Impl::POE based on POE, very slow, some limitations.
787
788=item Backends with special needs.
789
790Qt requires the Qt::Application to be instantiated first, but will
791otherwise be picked up automatically. As long as the main program
792instantiates the application before any AnyEvent watchers are created,
793everything should just work.
794
795 AnyEvent::Impl::Qt based on Qt.
796
797Support for IO::Async can only be partial, as it is too broken and
798architecturally limited to even support the AnyEvent API. It also
799is the only event loop that needs the loop to be set explicitly, so
800it can only be used by a main program knowing about AnyEvent. See
801L<AnyEvent::Impl::Async> for the gory details.
802
803 AnyEvent::Impl::IOAsync based on IO::Async, cannot be autoprobed.
804
805=item Event loops that are indirectly supported via other backends.
806
807Some event loops can be supported via other modules:
808
809There is no direct support for WxWidgets (L<Wx>) or L<Prima>.
810
811B<WxWidgets> has no support for watching file handles. However, you can
812use WxWidgets through the POE adaptor, as POE has a Wx backend that simply
813polls 20 times per second, which was considered to be too horrible to even
814consider for AnyEvent.
815
816B<Prima> is not supported as nobody seems to be using it, but it has a POE
817backend, so it can be supported through POE.
818
819AnyEvent knows about both L<Prima> and L<Wx>, however, and will try to
820load L<POE> when detecting them, in the hope that POE will pick them up,
821in which case everything will be automatic.
822
823=back
344 824
345=head1 GLOBAL VARIABLES AND FUNCTIONS 825=head1 GLOBAL VARIABLES AND FUNCTIONS
346 826
827These are not normally required to use AnyEvent, but can be useful to
828write AnyEvent extension modules.
829
347=over 4 830=over 4
348 831
349=item $AnyEvent::MODEL 832=item $AnyEvent::MODEL
350 833
351Contains C<undef> until the first watcher is being created. Then it 834Contains C<undef> until the first watcher is being created, before the
835backend has been autodetected.
836
352contains the event model that is being used, which is the name of the 837Afterwards it contains the event model that is being used, which is the
353Perl class implementing the model. This class is usually one of the 838name of the Perl class implementing the model. This class is usually one
354C<AnyEvent::Impl:xxx> modules, but can be any other class in the case 839of the C<AnyEvent::Impl:xxx> modules, but can be any other class in the
355AnyEvent has been extended at runtime (e.g. in I<rxvt-unicode>). 840case AnyEvent has been extended at runtime (e.g. in I<rxvt-unicode> it
356 841will be C<urxvt::anyevent>).
357The known classes so far are:
358
359 AnyEvent::Impl::CoroEV based on Coro::EV, best choice.
360 AnyEvent::Impl::CoroEvent based on Coro::Event, second best choice.
361 AnyEvent::Impl::EV based on EV (an interface to libev, best choice).
362 AnyEvent::Impl::Event based on Event, second best choice.
363 AnyEvent::Impl::Glib based on Glib, third-best choice.
364 AnyEvent::Impl::Tk based on Tk, very bad choice.
365 AnyEvent::Impl::Perl pure-perl implementation, inefficient but portable.
366 AnyEvent::Impl::Qt based on Qt, cannot be autoprobed (see its docs).
367 AnyEvent::Impl::EventLib based on Event::Lib, leaks memory and worse.
368 AnyEvent::Impl::POE based on POE, not generic enough for full support.
369
370There is no support for WxWidgets, as WxWidgets has no support for
371watching file handles. However, you can use WxWidgets through the
372POE Adaptor, as POE has a Wx backend that simply polls 20 times per
373second, which was considered to be too horrible to even consider for
374AnyEvent. Likewise, other POE backends can be used by AnyEvent by using
375it's adaptor.
376
377AnyEvent knows about L<Prima> and L<Wx> and will try to use L<POE> when
378autodetecting them.
379 842
380=item AnyEvent::detect 843=item AnyEvent::detect
381 844
382Returns C<$AnyEvent::MODEL>, forcing autodetection of the event model 845Returns C<$AnyEvent::MODEL>, forcing autodetection of the event model
383if necessary. You should only call this function right before you would 846if necessary. You should only call this function right before you would
384have created an AnyEvent watcher anyway, that is, as late as possible at 847have created an AnyEvent watcher anyway, that is, as late as possible at
385runtime. 848runtime, and not e.g. while initialising of your module.
849
850If you need to do some initialisation before AnyEvent watchers are
851created, use C<post_detect>.
852
853=item $guard = AnyEvent::post_detect { BLOCK }
854
855Arranges for the code block to be executed as soon as the event model is
856autodetected (or immediately if this has already happened).
857
858The block will be executed I<after> the actual backend has been detected
859(C<$AnyEvent::MODEL> is set), but I<before> any watchers have been
860created, so it is possible to e.g. patch C<@AnyEvent::ISA> or do
861other initialisations - see the sources of L<AnyEvent::Strict> or
862L<AnyEvent::AIO> to see how this is used.
863
864The most common usage is to create some global watchers, without forcing
865event module detection too early, for example, L<AnyEvent::AIO> creates
866and installs the global L<IO::AIO> watcher in a C<post_detect> block to
867avoid autodetecting the event module at load time.
868
869If called in scalar or list context, then it creates and returns an object
870that automatically removes the callback again when it is destroyed. See
871L<Coro::BDB> for a case where this is useful.
872
873=item @AnyEvent::post_detect
874
875If there are any code references in this array (you can C<push> to it
876before or after loading AnyEvent), then they will called directly after
877the event loop has been chosen.
878
879You should check C<$AnyEvent::MODEL> before adding to this array, though:
880if it is defined then the event loop has already been detected, and the
881array will be ignored.
882
883Best use C<AnyEvent::post_detect { BLOCK }> when your application allows
884it,as it takes care of these details.
885
886This variable is mainly useful for modules that can do something useful
887when AnyEvent is used and thus want to know when it is initialised, but do
888not need to even load it by default. This array provides the means to hook
889into AnyEvent passively, without loading it.
386 890
387=back 891=back
388 892
389=head1 WHAT TO DO IN A MODULE 893=head1 WHAT TO DO IN A MODULE
390 894
394Be careful when you create watchers in the module body - AnyEvent will 898Be careful when you create watchers in the module body - AnyEvent will
395decide which event module to use as soon as the first method is called, so 899decide which event module to use as soon as the first method is called, so
396by calling AnyEvent in your module body you force the user of your module 900by calling AnyEvent in your module body you force the user of your module
397to load the event module first. 901to load the event module first.
398 902
399Never call C<< ->wait >> on a condition variable unless you I<know> that 903Never call C<< ->recv >> on a condition variable unless you I<know> that
400the C<< ->broadcast >> method has been called on it already. This is 904the C<< ->send >> method has been called on it already. This is
401because it will stall the whole program, and the whole point of using 905because it will stall the whole program, and the whole point of using
402events is to stay interactive. 906events is to stay interactive.
403 907
404It is fine, however, to call C<< ->wait >> when the user of your module 908It is fine, however, to call C<< ->recv >> when the user of your module
405requests it (i.e. if you create a http request object ad have a method 909requests it (i.e. if you create a http request object ad have a method
406called C<results> that returns the results, it should call C<< ->wait >> 910called C<results> that returns the results, it should call C<< ->recv >>
407freely, as the user of your module knows what she is doing. always). 911freely, as the user of your module knows what she is doing. always).
408 912
409=head1 WHAT TO DO IN THE MAIN PROGRAM 913=head1 WHAT TO DO IN THE MAIN PROGRAM
410 914
411There will always be a single main program - the only place that should 915There will always be a single main program - the only place that should
413 917
414If it doesn't care, it can just "use AnyEvent" and use it itself, or not 918If it doesn't care, it can just "use AnyEvent" and use it itself, or not
415do anything special (it does not need to be event-based) and let AnyEvent 919do anything special (it does not need to be event-based) and let AnyEvent
416decide which implementation to chose if some module relies on it. 920decide which implementation to chose if some module relies on it.
417 921
418If the main program relies on a specific event model. For example, in 922If the main program relies on a specific event model - for example, in
419Gtk2 programs you have to rely on the Glib module. You should load the 923Gtk2 programs you have to rely on the Glib module - you should load the
420event module before loading AnyEvent or any module that uses it: generally 924event module before loading AnyEvent or any module that uses it: generally
421speaking, you should load it as early as possible. The reason is that 925speaking, you should load it as early as possible. The reason is that
422modules might create watchers when they are loaded, and AnyEvent will 926modules might create watchers when they are loaded, and AnyEvent will
423decide on the event model to use as soon as it creates watchers, and it 927decide on the event model to use as soon as it creates watchers, and it
424might chose the wrong one unless you load the correct one yourself. 928might chose the wrong one unless you load the correct one yourself.
425 929
426You can chose to use a rather inefficient pure-perl implementation by 930You can chose to use a pure-perl implementation by loading the
427loading the C<AnyEvent::Impl::Perl> module, which gives you similar 931C<AnyEvent::Impl::Perl> module, which gives you similar behaviour
428behaviour everywhere, but letting AnyEvent chose is generally better. 932everywhere, but letting AnyEvent chose the model is generally better.
933
934=head2 MAINLOOP EMULATION
935
936Sometimes (often for short test scripts, or even standalone programs who
937only want to use AnyEvent), you do not want to run a specific event loop.
938
939In that case, you can use a condition variable like this:
940
941 AnyEvent->condvar->recv;
942
943This has the effect of entering the event loop and looping forever.
944
945Note that usually your program has some exit condition, in which case
946it is better to use the "traditional" approach of storing a condition
947variable somewhere, waiting for it, and sending it when the program should
948exit cleanly.
949
950
951=head1 OTHER MODULES
952
953The following is a non-exhaustive list of additional modules that use
954AnyEvent as a client and can therefore be mixed easily with other AnyEvent
955modules and other event loops in the same program. Some of the modules
956come with AnyEvent, most are available via CPAN.
957
958=over 4
959
960=item L<AnyEvent::Util>
961
962Contains various utility functions that replace often-used but blocking
963functions such as C<inet_aton> by event-/callback-based versions.
964
965=item L<AnyEvent::Socket>
966
967Provides various utility functions for (internet protocol) sockets,
968addresses and name resolution. Also functions to create non-blocking tcp
969connections or tcp servers, with IPv6 and SRV record support and more.
970
971=item L<AnyEvent::Handle>
972
973Provide read and write buffers, manages watchers for reads and writes,
974supports raw and formatted I/O, I/O queued and fully transparent and
975non-blocking SSL/TLS (via L<AnyEvent::TLS>.
976
977=item L<AnyEvent::DNS>
978
979Provides rich asynchronous DNS resolver capabilities.
980
981=item L<AnyEvent::HTTP>
982
983A simple-to-use HTTP library that is capable of making a lot of concurrent
984HTTP requests.
985
986=item L<AnyEvent::HTTPD>
987
988Provides a simple web application server framework.
989
990=item L<AnyEvent::FastPing>
991
992The fastest ping in the west.
993
994=item L<AnyEvent::DBI>
995
996Executes L<DBI> requests asynchronously in a proxy process.
997
998=item L<AnyEvent::AIO>
999
1000Truly asynchronous I/O, should be in the toolbox of every event
1001programmer. AnyEvent::AIO transparently fuses L<IO::AIO> and AnyEvent
1002together.
1003
1004=item L<AnyEvent::BDB>
1005
1006Truly asynchronous Berkeley DB access. AnyEvent::BDB transparently fuses
1007L<BDB> and AnyEvent together.
1008
1009=item L<AnyEvent::GPSD>
1010
1011A non-blocking interface to gpsd, a daemon delivering GPS information.
1012
1013=item L<AnyEvent::IRC>
1014
1015AnyEvent based IRC client module family (replacing the older Net::IRC3).
1016
1017=item L<AnyEvent::XMPP>
1018
1019AnyEvent based XMPP (Jabber protocol) module family (replacing the older
1020Net::XMPP2>.
1021
1022=item L<AnyEvent::IGS>
1023
1024A non-blocking interface to the Internet Go Server protocol (used by
1025L<App::IGS>).
1026
1027=item L<Net::FCP>
1028
1029AnyEvent-based implementation of the Freenet Client Protocol, birthplace
1030of AnyEvent.
1031
1032=item L<Event::ExecFlow>
1033
1034High level API for event-based execution flow control.
1035
1036=item L<Coro>
1037
1038Has special support for AnyEvent via L<Coro::AnyEvent>.
1039
1040=back
429 1041
430=cut 1042=cut
431 1043
432package AnyEvent; 1044package AnyEvent;
433 1045
434no warnings; 1046no warnings;
435use strict; 1047use strict qw(vars subs);
436 1048
437use Carp; 1049use Carp ();
438 1050
439our $VERSION = '3.3'; 1051our $VERSION = 4.83;
440our $MODEL; 1052our $MODEL;
441 1053
442our $AUTOLOAD; 1054our $AUTOLOAD;
443our @ISA; 1055our @ISA;
444 1056
445our $verbose = $ENV{PERL_ANYEVENT_VERBOSE}*1;
446
447our @REGISTRY; 1057our @REGISTRY;
448 1058
1059our $WIN32;
1060
1061our $VERBOSE;
1062
1063BEGIN {
1064 eval "sub WIN32(){ " . (($^O =~ /mswin32/i)*1) ." }";
1065 eval "sub TAINT(){ " . (${^TAINT}*1) . " }";
1066
1067 delete @ENV{grep /^PERL_ANYEVENT_/, keys %ENV}
1068 if ${^TAINT};
1069
1070 $VERBOSE = $ENV{PERL_ANYEVENT_VERBOSE}*1;
1071
1072}
1073
1074our $MAX_SIGNAL_LATENCY = 10;
1075
1076our %PROTOCOL; # (ipv4|ipv6) => (1|2), higher numbers are preferred
1077
1078{
1079 my $idx;
1080 $PROTOCOL{$_} = ++$idx
1081 for reverse split /\s*,\s*/,
1082 $ENV{PERL_ANYEVENT_PROTOCOLS} || "ipv4,ipv6";
1083}
1084
449my @models = ( 1085my @models = (
450 [Coro::EV:: => AnyEvent::Impl::CoroEV::],
451 [Coro::Event:: => AnyEvent::Impl::CoroEvent::],
452 [EV:: => AnyEvent::Impl::EV::], 1086 [EV:: => AnyEvent::Impl::EV::],
453 [Event:: => AnyEvent::Impl::Event::], 1087 [Event:: => AnyEvent::Impl::Event::],
454 [Glib:: => AnyEvent::Impl::Glib::], 1088 [AnyEvent::Impl::Perl:: => AnyEvent::Impl::Perl::],
1089 # everything below here will not be autoprobed
1090 # as the pureperl backend should work everywhere
1091 # and is usually faster
1092 [Glib:: => AnyEvent::Impl::Glib::], # becomes extremely slow with many watchers
1093 [Event::Lib:: => AnyEvent::Impl::EventLib::], # too buggy
455 [Tk:: => AnyEvent::Impl::Tk::], 1094 [Tk:: => AnyEvent::Impl::Tk::], # crashes with many handles
1095 [Qt:: => AnyEvent::Impl::Qt::], # requires special main program
1096 [POE::Kernel:: => AnyEvent::Impl::POE::], # lasciate ogni speranza
456 [Wx:: => AnyEvent::Impl::POE::], 1097 [Wx:: => AnyEvent::Impl::POE::],
457 [Prima:: => AnyEvent::Impl::POE::], 1098 [Prima:: => AnyEvent::Impl::POE::],
458 [AnyEvent::Impl::Perl:: => AnyEvent::Impl::Perl::], 1099 # IO::Async is just too broken - we would need workarounds for its
459 # everything below here will not be autoprobed as the pureperl backend should work everywhere 1100 # byzantine signal and broken child handling, among others.
460 [Event::Lib:: => AnyEvent::Impl::EventLib::], # too buggy 1101 # IO::Async is rather hard to detect, as it doesn't have any
1102 # obvious default class.
461 [Qt:: => AnyEvent::Impl::Qt::], # requires special main program 1103# [IO::Async:: => AnyEvent::Impl::IOAsync::], # requires special main program
462 [POE::Kernel:: => AnyEvent::Impl::POE::], # lasciate ogni speranza 1104# [IO::Async::Loop:: => AnyEvent::Impl::IOAsync::], # requires special main program
1105# [IO::Async::Notifier:: => AnyEvent::Impl::IOAsync::], # requires special main program
463); 1106);
464 1107
465our %method = map +($_ => 1), qw(io timer signal child condvar broadcast wait one_event DESTROY); 1108our %method = map +($_ => 1),
1109 qw(io timer time now now_update signal child idle condvar one_event DESTROY);
1110
1111our @post_detect;
1112
1113sub post_detect(&) {
1114 my ($cb) = @_;
1115
1116 if ($MODEL) {
1117 $cb->();
1118
1119 1
1120 } else {
1121 push @post_detect, $cb;
1122
1123 defined wantarray
1124 ? bless \$cb, "AnyEvent::Util::postdetect"
1125 : ()
1126 }
1127}
1128
1129sub AnyEvent::Util::postdetect::DESTROY {
1130 @post_detect = grep $_ != ${$_[0]}, @post_detect;
1131}
466 1132
467sub detect() { 1133sub detect() {
468 unless ($MODEL) { 1134 unless ($MODEL) {
469 no strict 'refs'; 1135 no strict 'refs';
1136 local $SIG{__DIE__};
470 1137
471 if ($ENV{PERL_ANYEVENT_MODEL} =~ /^([a-zA-Z]+)$/) { 1138 if ($ENV{PERL_ANYEVENT_MODEL} =~ /^([a-zA-Z]+)$/) {
472 my $model = "AnyEvent::Impl::$1"; 1139 my $model = "AnyEvent::Impl::$1";
473 if (eval "require $model") { 1140 if (eval "require $model") {
474 $MODEL = $model; 1141 $MODEL = $model;
475 warn "AnyEvent: loaded model '$model' (forced by \$PERL_ANYEVENT_MODEL), using it.\n" if $verbose > 1; 1142 warn "AnyEvent: loaded model '$model' (forced by \$ENV{PERL_ANYEVENT_MODEL}), using it.\n" if $VERBOSE >= 2;
476 } else { 1143 } else {
477 warn "AnyEvent: unable to load model '$model' (from \$PERL_ANYEVENT_MODEL):\n$@" if $verbose; 1144 warn "AnyEvent: unable to load model '$model' (from \$ENV{PERL_ANYEVENT_MODEL}):\n$@" if $VERBOSE;
478 } 1145 }
479 } 1146 }
480 1147
481 # check for already loaded models 1148 # check for already loaded models
482 unless ($MODEL) { 1149 unless ($MODEL) {
483 for (@REGISTRY, @models) { 1150 for (@REGISTRY, @models) {
484 my ($package, $model) = @$_; 1151 my ($package, $model) = @$_;
485 if (${"$package\::VERSION"} > 0) { 1152 if (${"$package\::VERSION"} > 0) {
486 if (eval "require $model") { 1153 if (eval "require $model") {
487 $MODEL = $model; 1154 $MODEL = $model;
488 warn "AnyEvent: autodetected model '$model', using it.\n" if $verbose > 1; 1155 warn "AnyEvent: autodetected model '$model', using it.\n" if $VERBOSE >= 2;
489 last; 1156 last;
490 } 1157 }
491 } 1158 }
492 } 1159 }
493 1160
498 my ($package, $model) = @$_; 1165 my ($package, $model) = @$_;
499 if (eval "require $package" 1166 if (eval "require $package"
500 and ${"$package\::VERSION"} > 0 1167 and ${"$package\::VERSION"} > 0
501 and eval "require $model") { 1168 and eval "require $model") {
502 $MODEL = $model; 1169 $MODEL = $model;
503 warn "AnyEvent: autoprobed model '$model', using it.\n" if $verbose > 1; 1170 warn "AnyEvent: autoprobed model '$model', using it.\n" if $VERBOSE >= 2;
504 last; 1171 last;
505 } 1172 }
506 } 1173 }
507 1174
508 $MODEL 1175 $MODEL
509 or die "No event module selected for AnyEvent and autodetect failed. Install any one of these modules: EV (or Coro+EV), Event (or Coro+Event) or Glib."; 1176 or die "No event module selected for AnyEvent and autodetect failed. Install any one of these modules: EV, Event or Glib.\n";
510 } 1177 }
511 } 1178 }
512 1179
1180 push @{"$MODEL\::ISA"}, "AnyEvent::Base";
1181
513 unshift @ISA, $MODEL; 1182 unshift @ISA, $MODEL;
514 push @{"$MODEL\::ISA"}, "AnyEvent::Base"; 1183
1184 require AnyEvent::Strict if $ENV{PERL_ANYEVENT_STRICT};
1185
1186 (shift @post_detect)->() while @post_detect;
515 } 1187 }
516 1188
517 $MODEL 1189 $MODEL
518} 1190}
519 1191
520sub AUTOLOAD { 1192sub AUTOLOAD {
521 (my $func = $AUTOLOAD) =~ s/.*://; 1193 (my $func = $AUTOLOAD) =~ s/.*://;
522 1194
523 $method{$func} 1195 $method{$func}
524 or croak "$func: not a valid method for AnyEvent objects"; 1196 or Carp::croak "$func: not a valid method for AnyEvent objects";
525 1197
526 detect unless $MODEL; 1198 detect unless $MODEL;
527 1199
528 my $class = shift; 1200 my $class = shift;
529 $class->$func (@_); 1201 $class->$func (@_);
530} 1202}
531 1203
1204# utility function to dup a filehandle. this is used by many backends
1205# to support binding more than one watcher per filehandle (they usually
1206# allow only one watcher per fd, so we dup it to get a different one).
1207sub _dupfh($$;$$) {
1208 my ($poll, $fh, $r, $w) = @_;
1209
1210 # cygwin requires the fh mode to be matching, unix doesn't
1211 my ($rw, $mode) = $poll eq "r" ? ($r, "<&") : ($w, ">&");
1212
1213 open my $fh2, $mode, $fh
1214 or die "AnyEvent->io: cannot dup() filehandle in mode '$poll': $!,";
1215
1216 # we assume CLOEXEC is already set by perl in all important cases
1217
1218 ($fh2, $rw)
1219}
1220
532package AnyEvent::Base; 1221package AnyEvent::Base;
533 1222
1223# default implementations for many methods
1224
1225sub _time {
1226 # probe for availability of Time::HiRes
1227 if (eval "use Time::HiRes (); Time::HiRes::time (); 1") {
1228 warn "AnyEvent: using Time::HiRes for sub-second timing accuracy.\n" if $VERBOSE >= 8;
1229 *_time = \&Time::HiRes::time;
1230 # if (eval "use POSIX (); (POSIX::times())...
1231 } else {
1232 warn "AnyEvent: using built-in time(), WARNING, no sub-second resolution!\n" if $VERBOSE;
1233 *_time = sub { time }; # epic fail
1234 }
1235
1236 &_time
1237}
1238
1239sub time { _time }
1240sub now { _time }
1241sub now_update { }
1242
534# default implementation for ->condvar, ->wait, ->broadcast 1243# default implementation for ->condvar
535 1244
536sub condvar { 1245sub condvar {
537 bless \my $flag, "AnyEvent::Base::CondVar" 1246 bless { @_ == 3 ? (_ae_cb => $_[2]) : () }, "AnyEvent::CondVar"
538}
539
540sub AnyEvent::Base::CondVar::broadcast {
541 ${$_[0]}++;
542}
543
544sub AnyEvent::Base::CondVar::wait {
545 AnyEvent->one_event while !${$_[0]};
546} 1247}
547 1248
548# default implementation for ->signal 1249# default implementation for ->signal
549 1250
550our %SIG_CB; 1251our $HAVE_ASYNC_INTERRUPT;
1252our ($SIGPIPE_R, $SIGPIPE_W, %SIG_CB, %SIG_EV, $SIG_IO);
1253our (%SIG_ASY, %SIG_ASY_W);
1254our ($SIG_COUNT, $SIG_TW);
551 1255
1256sub _signal_exec {
1257 $HAVE_ASYNC_INTERRUPT
1258 ? $SIGPIPE_R->drain
1259 : sysread $SIGPIPE_R, my $dummy, 9;
1260
1261 while (%SIG_EV) {
1262 for (keys %SIG_EV) {
1263 delete $SIG_EV{$_};
1264 $_->() for values %{ $SIG_CB{$_} || {} };
1265 }
1266 }
1267}
1268
552sub signal { 1269sub _signal {
553 my (undef, %arg) = @_; 1270 my (undef, %arg) = @_;
554 1271
555 my $signal = uc $arg{signal} 1272 my $signal = uc $arg{signal}
556 or Carp::croak "required option 'signal' is missing"; 1273 or Carp::croak "required option 'signal' is missing";
557 1274
558 $SIG_CB{$signal}{$arg{cb}} = $arg{cb}; 1275 $SIG_CB{$signal}{$arg{cb}} = $arg{cb};
1276
1277 if ($HAVE_ASYNC_INTERRUPT) {
1278 # async::interrupt
1279
1280 $SIG_ASY{$signal} ||= do {
1281 my $asy = new Async::Interrupt
1282 cb => sub { undef $SIG_EV{$signal} },
1283 signal => $signal,
1284 pipe => [$SIGPIPE_R->filenos],
1285 ;
1286 $asy->pipe_autodrain (0);
1287
1288 $asy
1289 };
1290
1291 } else {
1292 # pure perl
1293
559 $SIG{$signal} ||= sub { 1294 $SIG{$signal} ||= sub {
560 $_->() for values %{ $SIG_CB{$signal} || {} }; 1295 local $!;
1296 syswrite $SIGPIPE_W, "\x00", 1 unless %SIG_EV;
1297 undef $SIG_EV{$signal};
1298 };
1299
1300 # can't do signal processing without introducing races in pure perl,
1301 # so limit the signal latency.
1302 ++$SIG_COUNT;
1303 $SIG_TW ||= AnyEvent->timer (
1304 after => $MAX_SIGNAL_LATENCY,
1305 interval => $MAX_SIGNAL_LATENCY,
1306 cb => sub { }, # just for the PERL_ASYNC_CHECK
1307 );
561 }; 1308 }
562 1309
563 bless [$signal, $arg{cb}], "AnyEvent::Base::Signal" 1310 bless [$signal, $arg{cb}], "AnyEvent::Base::signal"
564} 1311}
565 1312
1313sub signal {
1314 # probe for availability of Async::Interrupt
1315 if (!$ENV{PERL_ANYEVENT_AVOID_ASYNC_INTERRUPT} && eval "use Async::Interrupt 0.6 (); 1") {
1316 warn "AnyEvent: using Async::Interrupt for race-free signal handling.\n" if $VERBOSE >= 8;
1317
1318 $HAVE_ASYNC_INTERRUPT = 1;
1319 $SIGPIPE_R = new Async::Interrupt::EventPipe;
1320 $SIG_IO = AnyEvent->io (fh => $SIGPIPE_R->fileno, poll => "r", cb => \&_signal_exec);
1321
1322 } else {
1323 warn "AnyEvent: using emulated perl signal handling with latency timer.\n" if $VERBOSE >= 8;
1324
1325 require Fcntl;
1326
1327 if (AnyEvent::WIN32) {
1328 require AnyEvent::Util;
1329
1330 ($SIGPIPE_R, $SIGPIPE_W) = AnyEvent::Util::portable_pipe ();
1331 AnyEvent::Util::fh_nonblocking ($SIGPIPE_R) if $SIGPIPE_R;
1332 AnyEvent::Util::fh_nonblocking ($SIGPIPE_W) if $SIGPIPE_W; # just in case
1333 } else {
1334 pipe $SIGPIPE_R, $SIGPIPE_W;
1335 fcntl $SIGPIPE_R, &Fcntl::F_SETFL, &Fcntl::O_NONBLOCK if $SIGPIPE_R;
1336 fcntl $SIGPIPE_W, &Fcntl::F_SETFL, &Fcntl::O_NONBLOCK if $SIGPIPE_W; # just in case
1337
1338 # not strictly required, as $^F is normally 2, but let's make sure...
1339 fcntl $SIGPIPE_R, &Fcntl::F_SETFD, &Fcntl::FD_CLOEXEC;
1340 fcntl $SIGPIPE_W, &Fcntl::F_SETFD, &Fcntl::FD_CLOEXEC;
1341 }
1342
1343 $SIGPIPE_R
1344 or Carp::croak "AnyEvent: unable to create a signal reporting pipe: $!\n";
1345
1346 $SIG_IO = AnyEvent->io (fh => $SIGPIPE_R, poll => "r", cb => \&_signal_exec);
1347 }
1348
1349 *signal = \&_signal;
1350 &signal
1351}
1352
566sub AnyEvent::Base::Signal::DESTROY { 1353sub AnyEvent::Base::signal::DESTROY {
567 my ($signal, $cb) = @{$_[0]}; 1354 my ($signal, $cb) = @{$_[0]};
568 1355
1356 undef $SIG_TW
1357 unless --$SIG_COUNT;
1358
569 delete $SIG_CB{$signal}{$cb}; 1359 delete $SIG_CB{$signal}{$cb};
570 1360
571 $SIG{$signal} = 'DEFAULT' unless keys %{ $SIG_CB{$signal} }; 1361 # delete doesn't work with older perls - they then
1362 # print weird messages, or just unconditionally exit
1363 # instead of getting the default action.
1364 undef $SIG{$signal}
1365 unless keys %{ $SIG_CB{$signal} };
572} 1366}
573 1367
574# default implementation for ->child 1368# default implementation for ->child
575 1369
576our %PID_CB; 1370our %PID_CB;
577our $CHLD_W; 1371our $CHLD_W;
578our $CHLD_DELAY_W; 1372our $CHLD_DELAY_W;
579our $PID_IDLE;
580our $WNOHANG; 1373our $WNOHANG;
581 1374
582sub _child_wait { 1375sub _sigchld {
583 while (0 < (my $pid = waitpid -1, $WNOHANG)) { 1376 while (0 < (my $pid = waitpid -1, $WNOHANG)) {
1377 $_->($pid, $?)
584 $_->($pid, $?) for (values %{ $PID_CB{$pid} || {} }), 1378 for values %{ $PID_CB{$pid} || {} },
585 (values %{ $PID_CB{0} || {} }); 1379 values %{ $PID_CB{0} || {} };
586 } 1380 }
587
588 undef $PID_IDLE;
589}
590
591sub _sigchld {
592 # make sure we deliver these changes "synchronous" with the event loop.
593 $CHLD_DELAY_W ||= AnyEvent->timer (after => 0, cb => sub {
594 undef $CHLD_DELAY_W;
595 &_child_wait;
596 });
597} 1381}
598 1382
599sub child { 1383sub child {
600 my (undef, %arg) = @_; 1384 my (undef, %arg) = @_;
601 1385
602 defined (my $pid = $arg{pid} + 0) 1386 defined (my $pid = $arg{pid} + 0)
603 or Carp::croak "required option 'pid' is missing"; 1387 or Carp::croak "required option 'pid' is missing";
604 1388
605 $PID_CB{$pid}{$arg{cb}} = $arg{cb}; 1389 $PID_CB{$pid}{$arg{cb}} = $arg{cb};
606 1390
607 unless ($WNOHANG) {
608 $WNOHANG = eval { require POSIX; &POSIX::WNOHANG } || 1; 1391 $WNOHANG ||= eval { local $SIG{__DIE__}; require POSIX; &POSIX::WNOHANG } || 1;
609 }
610 1392
611 unless ($CHLD_W) { 1393 unless ($CHLD_W) {
612 $CHLD_W = AnyEvent->signal (signal => 'CHLD', cb => \&_sigchld); 1394 $CHLD_W = AnyEvent->signal (signal => 'CHLD', cb => \&_sigchld);
613 # child could be a zombie already, so make at least one round 1395 # child could be a zombie already, so make at least one round
614 &_sigchld; 1396 &_sigchld;
615 } 1397 }
616 1398
617 bless [$pid, $arg{cb}], "AnyEvent::Base::Child" 1399 bless [$pid, $arg{cb}], "AnyEvent::Base::child"
618} 1400}
619 1401
620sub AnyEvent::Base::Child::DESTROY { 1402sub AnyEvent::Base::child::DESTROY {
621 my ($pid, $cb) = @{$_[0]}; 1403 my ($pid, $cb) = @{$_[0]};
622 1404
623 delete $PID_CB{$pid}{$cb}; 1405 delete $PID_CB{$pid}{$cb};
624 delete $PID_CB{$pid} unless keys %{ $PID_CB{$pid} }; 1406 delete $PID_CB{$pid} unless keys %{ $PID_CB{$pid} };
625 1407
626 undef $CHLD_W unless keys %PID_CB; 1408 undef $CHLD_W unless keys %PID_CB;
627} 1409}
1410
1411# idle emulation is done by simply using a timer, regardless
1412# of whether the process is idle or not, and not letting
1413# the callback use more than 50% of the time.
1414sub idle {
1415 my (undef, %arg) = @_;
1416
1417 my ($cb, $w, $rcb) = $arg{cb};
1418
1419 $rcb = sub {
1420 if ($cb) {
1421 $w = _time;
1422 &$cb;
1423 $w = _time - $w;
1424
1425 # never use more then 50% of the time for the idle watcher,
1426 # within some limits
1427 $w = 0.0001 if $w < 0.0001;
1428 $w = 5 if $w > 5;
1429
1430 $w = AnyEvent->timer (after => $w, cb => $rcb);
1431 } else {
1432 # clean up...
1433 undef $w;
1434 undef $rcb;
1435 }
1436 };
1437
1438 $w = AnyEvent->timer (after => 0.05, cb => $rcb);
1439
1440 bless \\$cb, "AnyEvent::Base::idle"
1441}
1442
1443sub AnyEvent::Base::idle::DESTROY {
1444 undef $${$_[0]};
1445}
1446
1447package AnyEvent::CondVar;
1448
1449our @ISA = AnyEvent::CondVar::Base::;
1450
1451package AnyEvent::CondVar::Base;
1452
1453use overload
1454 '&{}' => sub { my $self = shift; sub { $self->send (@_) } },
1455 fallback => 1;
1456
1457our $WAITING;
1458
1459sub _send {
1460 # nop
1461}
1462
1463sub send {
1464 my $cv = shift;
1465 $cv->{_ae_sent} = [@_];
1466 (delete $cv->{_ae_cb})->($cv) if $cv->{_ae_cb};
1467 $cv->_send;
1468}
1469
1470sub croak {
1471 $_[0]{_ae_croak} = $_[1];
1472 $_[0]->send;
1473}
1474
1475sub ready {
1476 $_[0]{_ae_sent}
1477}
1478
1479sub _wait {
1480 $WAITING
1481 and !$_[0]{_ae_sent}
1482 and Carp::croak "AnyEvent::CondVar: recursive blocking wait detected";
1483
1484 local $WAITING = 1;
1485 AnyEvent->one_event while !$_[0]{_ae_sent};
1486}
1487
1488sub recv {
1489 $_[0]->_wait;
1490
1491 Carp::croak $_[0]{_ae_croak} if $_[0]{_ae_croak};
1492 wantarray ? @{ $_[0]{_ae_sent} } : $_[0]{_ae_sent}[0]
1493}
1494
1495sub cb {
1496 $_[0]{_ae_cb} = $_[1] if @_ > 1;
1497 $_[0]{_ae_cb}
1498}
1499
1500sub begin {
1501 ++$_[0]{_ae_counter};
1502 $_[0]{_ae_end_cb} = $_[1] if @_ > 1;
1503}
1504
1505sub end {
1506 return if --$_[0]{_ae_counter};
1507 &{ $_[0]{_ae_end_cb} || sub { $_[0]->send } };
1508}
1509
1510# undocumented/compatibility with pre-3.4
1511*broadcast = \&send;
1512*wait = \&_wait;
1513
1514=head1 ERROR AND EXCEPTION HANDLING
1515
1516In general, AnyEvent does not do any error handling - it relies on the
1517caller to do that if required. The L<AnyEvent::Strict> module (see also
1518the C<PERL_ANYEVENT_STRICT> environment variable, below) provides strict
1519checking of all AnyEvent methods, however, which is highly useful during
1520development.
1521
1522As for exception handling (i.e. runtime errors and exceptions thrown while
1523executing a callback), this is not only highly event-loop specific, but
1524also not in any way wrapped by this module, as this is the job of the main
1525program.
1526
1527The pure perl event loop simply re-throws the exception (usually
1528within C<< condvar->recv >>), the L<Event> and L<EV> modules call C<<
1529$Event/EV::DIED->() >>, L<Glib> uses C<< install_exception_handler >> and
1530so on.
1531
1532=head1 ENVIRONMENT VARIABLES
1533
1534The following environment variables are used by this module or its
1535submodules.
1536
1537Note that AnyEvent will remove I<all> environment variables starting with
1538C<PERL_ANYEVENT_> from C<%ENV> when it is loaded while taint mode is
1539enabled.
1540
1541=over 4
1542
1543=item C<PERL_ANYEVENT_VERBOSE>
1544
1545By default, AnyEvent will be completely silent except in fatal
1546conditions. You can set this environment variable to make AnyEvent more
1547talkative.
1548
1549When set to C<1> or higher, causes AnyEvent to warn about unexpected
1550conditions, such as not being able to load the event model specified by
1551C<PERL_ANYEVENT_MODEL>.
1552
1553When set to C<2> or higher, cause AnyEvent to report to STDERR which event
1554model it chooses.
1555
1556=item C<PERL_ANYEVENT_STRICT>
1557
1558AnyEvent does not do much argument checking by default, as thorough
1559argument checking is very costly. Setting this variable to a true value
1560will cause AnyEvent to load C<AnyEvent::Strict> and then to thoroughly
1561check the arguments passed to most method calls. If it finds any problems,
1562it will croak.
1563
1564In other words, enables "strict" mode.
1565
1566Unlike C<use strict>, it is definitely recommended to keep it off in
1567production. Keeping C<PERL_ANYEVENT_STRICT=1> in your environment while
1568developing programs can be very useful, however.
1569
1570=item C<PERL_ANYEVENT_MODEL>
1571
1572This can be used to specify the event model to be used by AnyEvent, before
1573auto detection and -probing kicks in. It must be a string consisting
1574entirely of ASCII letters. The string C<AnyEvent::Impl::> gets prepended
1575and the resulting module name is loaded and if the load was successful,
1576used as event model. If it fails to load AnyEvent will proceed with
1577auto detection and -probing.
1578
1579This functionality might change in future versions.
1580
1581For example, to force the pure perl model (L<AnyEvent::Impl::Perl>) you
1582could start your program like this:
1583
1584 PERL_ANYEVENT_MODEL=Perl perl ...
1585
1586=item C<PERL_ANYEVENT_PROTOCOLS>
1587
1588Used by both L<AnyEvent::DNS> and L<AnyEvent::Socket> to determine preferences
1589for IPv4 or IPv6. The default is unspecified (and might change, or be the result
1590of auto probing).
1591
1592Must be set to a comma-separated list of protocols or address families,
1593current supported: C<ipv4> and C<ipv6>. Only protocols mentioned will be
1594used, and preference will be given to protocols mentioned earlier in the
1595list.
1596
1597This variable can effectively be used for denial-of-service attacks
1598against local programs (e.g. when setuid), although the impact is likely
1599small, as the program has to handle conenction and other failures anyways.
1600
1601Examples: C<PERL_ANYEVENT_PROTOCOLS=ipv4,ipv6> - prefer IPv4 over IPv6,
1602but support both and try to use both. C<PERL_ANYEVENT_PROTOCOLS=ipv4>
1603- only support IPv4, never try to resolve or contact IPv6
1604addresses. C<PERL_ANYEVENT_PROTOCOLS=ipv6,ipv4> support either IPv4 or
1605IPv6, but prefer IPv6 over IPv4.
1606
1607=item C<PERL_ANYEVENT_EDNS0>
1608
1609Used by L<AnyEvent::DNS> to decide whether to use the EDNS0 extension
1610for DNS. This extension is generally useful to reduce DNS traffic, but
1611some (broken) firewalls drop such DNS packets, which is why it is off by
1612default.
1613
1614Setting this variable to C<1> will cause L<AnyEvent::DNS> to announce
1615EDNS0 in its DNS requests.
1616
1617=item C<PERL_ANYEVENT_MAX_FORKS>
1618
1619The maximum number of child processes that C<AnyEvent::Util::fork_call>
1620will create in parallel.
1621
1622=item C<PERL_ANYEVENT_MAX_OUTSTANDING_DNS>
1623
1624The default value for the C<max_outstanding> parameter for the default DNS
1625resolver - this is the maximum number of parallel DNS requests that are
1626sent to the DNS server.
1627
1628=item C<PERL_ANYEVENT_RESOLV_CONF>
1629
1630The file to use instead of F</etc/resolv.conf> (or OS-specific
1631configuration) in the default resolver. When set to the empty string, no
1632default config will be used.
1633
1634=item C<PERL_ANYEVENT_CA_FILE>, C<PERL_ANYEVENT_CA_PATH>.
1635
1636When neither C<ca_file> nor C<ca_path> was specified during
1637L<AnyEvent::TLS> context creation, and either of these environment
1638variables exist, they will be used to specify CA certificate locations
1639instead of a system-dependent default.
1640
1641=back
628 1642
629=head1 SUPPLYING YOUR OWN EVENT MODEL INTERFACE 1643=head1 SUPPLYING YOUR OWN EVENT MODEL INTERFACE
630 1644
631This is an advanced topic that you do not normally need to use AnyEvent in 1645This is an advanced topic that you do not normally need to use AnyEvent in
632a module. This section is only of use to event loop authors who want to 1646a module. This section is only of use to event loop authors who want to
667I<rxvt-unicode> also cheats a bit by not providing blocking access to 1681I<rxvt-unicode> also cheats a bit by not providing blocking access to
668condition variables: code blocking while waiting for a condition will 1682condition variables: code blocking while waiting for a condition will
669C<die>. This still works with most modules/usages, and blocking calls must 1683C<die>. This still works with most modules/usages, and blocking calls must
670not be done in an interactive application, so it makes sense. 1684not be done in an interactive application, so it makes sense.
671 1685
672=head1 ENVIRONMENT VARIABLES
673
674The following environment variables are used by this module:
675
676=over 4
677
678=item C<PERL_ANYEVENT_VERBOSE>
679
680By default, AnyEvent will be completely silent except in fatal
681conditions. You can set this environment variable to make AnyEvent more
682talkative.
683
684When set to C<1> or higher, causes AnyEvent to warn about unexpected
685conditions, such as not being able to load the event model specified by
686C<PERL_ANYEVENT_MODEL>.
687
688When set to C<2> or higher, cause AnyEvent to report to STDERR which event
689model it chooses.
690
691=item C<PERL_ANYEVENT_MODEL>
692
693This can be used to specify the event model to be used by AnyEvent, before
694autodetection and -probing kicks in. It must be a string consisting
695entirely of ASCII letters. The string C<AnyEvent::Impl::> gets prepended
696and the resulting module name is loaded and if the load was successful,
697used as event model. If it fails to load AnyEvent will proceed with
698autodetection and -probing.
699
700This functionality might change in future versions.
701
702For example, to force the pure perl model (L<AnyEvent::Impl::Perl>) you
703could start your program like this:
704
705 PERL_ANYEVENT_MODEL=Perl perl ...
706
707=back
708
709=head1 EXAMPLE PROGRAM 1686=head1 EXAMPLE PROGRAM
710 1687
711The following program uses an IO watcher to read data from STDIN, a timer 1688The following program uses an I/O watcher to read data from STDIN, a timer
712to display a message once per second, and a condition variable to quit the 1689to display a message once per second, and a condition variable to quit the
713program when the user enters quit: 1690program when the user enters quit:
714 1691
715 use AnyEvent; 1692 use AnyEvent;
716 1693
721 poll => 'r', 1698 poll => 'r',
722 cb => sub { 1699 cb => sub {
723 warn "io event <$_[0]>\n"; # will always output <r> 1700 warn "io event <$_[0]>\n"; # will always output <r>
724 chomp (my $input = <STDIN>); # read a line 1701 chomp (my $input = <STDIN>); # read a line
725 warn "read: $input\n"; # output what has been read 1702 warn "read: $input\n"; # output what has been read
726 $cv->broadcast if $input =~ /^q/i; # quit program if /^q/i 1703 $cv->send if $input =~ /^q/i; # quit program if /^q/i
727 }, 1704 },
728 ); 1705 );
729 1706
730 my $time_watcher; # can only be used once 1707 my $time_watcher; # can only be used once
731 1708
736 }); 1713 });
737 } 1714 }
738 1715
739 new_timer; # create first timer 1716 new_timer; # create first timer
740 1717
741 $cv->wait; # wait until user enters /^q/i 1718 $cv->recv; # wait until user enters /^q/i
742 1719
743=head1 REAL-WORLD EXAMPLE 1720=head1 REAL-WORLD EXAMPLE
744 1721
745Consider the L<Net::FCP> module. It features (among others) the following 1722Consider the L<Net::FCP> module. It features (among others) the following
746API calls, which are to freenet what HTTP GET requests are to http: 1723API calls, which are to freenet what HTTP GET requests are to http:
796 syswrite $txn->{fh}, $txn->{request} 1773 syswrite $txn->{fh}, $txn->{request}
797 or die "connection or write error"; 1774 or die "connection or write error";
798 $txn->{w} = AnyEvent->io (fh => $txn->{fh}, poll => 'r', cb => sub { $txn->fh_ready_r }); 1775 $txn->{w} = AnyEvent->io (fh => $txn->{fh}, poll => 'r', cb => sub { $txn->fh_ready_r });
799 1776
800Again, C<fh_ready_r> waits till all data has arrived, and then stores the 1777Again, C<fh_ready_r> waits till all data has arrived, and then stores the
801result and signals any possible waiters that the request ahs finished: 1778result and signals any possible waiters that the request has finished:
802 1779
803 sysread $txn->{fh}, $txn->{buf}, length $txn->{$buf}; 1780 sysread $txn->{fh}, $txn->{buf}, length $txn->{$buf};
804 1781
805 if (end-of-file or data complete) { 1782 if (end-of-file or data complete) {
806 $txn->{result} = $txn->{buf}; 1783 $txn->{result} = $txn->{buf};
807 $txn->{finished}->broadcast; 1784 $txn->{finished}->send;
808 $txb->{cb}->($txn) of $txn->{cb}; # also call callback 1785 $txb->{cb}->($txn) of $txn->{cb}; # also call callback
809 } 1786 }
810 1787
811The C<result> method, finally, just waits for the finished signal (if the 1788The C<result> method, finally, just waits for the finished signal (if the
812request was already finished, it doesn't wait, of course, and returns the 1789request was already finished, it doesn't wait, of course, and returns the
813data: 1790data:
814 1791
815 $txn->{finished}->wait; 1792 $txn->{finished}->recv;
816 return $txn->{result}; 1793 return $txn->{result};
817 1794
818The actual code goes further and collects all errors (C<die>s, exceptions) 1795The actual code goes further and collects all errors (C<die>s, exceptions)
819that occured during request processing. The C<result> method detects 1796that occurred during request processing. The C<result> method detects
820whether an exception as thrown (it is stored inside the $txn object) 1797whether an exception as thrown (it is stored inside the $txn object)
821and just throws the exception, which means connection errors and other 1798and just throws the exception, which means connection errors and other
822problems get reported tot he code that tries to use the result, not in a 1799problems get reported tot he code that tries to use the result, not in a
823random callback. 1800random callback.
824 1801
855 1832
856 my $quit = AnyEvent->condvar; 1833 my $quit = AnyEvent->condvar;
857 1834
858 $fcp->txn_client_get ($url)->cb (sub { 1835 $fcp->txn_client_get ($url)->cb (sub {
859 ... 1836 ...
860 $quit->broadcast; 1837 $quit->send;
861 }); 1838 });
862 1839
863 $quit->wait; 1840 $quit->recv;
864 1841
865 1842
866=head1 BENCHMARK 1843=head1 BENCHMARKS
867 1844
868To give you an idea of the performance and overheads that AnyEvent adds 1845To give you an idea of the performance and overheads that AnyEvent adds
869over the backends directly, here is a benchmark of various supported event 1846over the event loops themselves and to give you an impression of the speed
870models natively and with anyevent. The benchmark creates a lot of timers 1847of various event loops I prepared some benchmarks.
1848
1849=head2 BENCHMARKING ANYEVENT OVERHEAD
1850
1851Here is a benchmark of various supported event models used natively and
1852through AnyEvent. The benchmark creates a lot of timers (with a zero
871(with a zero timeout) and io watchers (watching STDOUT, a pty, to become 1853timeout) and I/O watchers (watching STDOUT, a pty, to become writable,
872writable, which it is), lets them fire exactly once and destroys them 1854which it is), lets them fire exactly once and destroys them again.
873again.
874 1855
875Explanation of the fields: 1856Source code for this benchmark is found as F<eg/bench> in the AnyEvent
1857distribution.
876 1858
1859=head3 Explanation of the columns
1860
877I<watcher> is the number of event watchers created/destroyed. Sicne 1861I<watcher> is the number of event watchers created/destroyed. Since
878different event models have vastly different performance each backend was 1862different event models feature vastly different performances, each event
879handed a number of watchers so that overall runtime is acceptable and 1863loop was given a number of watchers so that overall runtime is acceptable
880similar to all backends (and keep them from crashing). 1864and similar between tested event loop (and keep them from crashing): Glib
1865would probably take thousands of years if asked to process the same number
1866of watchers as EV in this benchmark.
881 1867
882I<bytes> is the number of bytes (as measured by resident set size) used by 1868I<bytes> is the number of bytes (as measured by the resident set size,
883each watcher. 1869RSS) consumed by each watcher. This method of measuring captures both C
1870and Perl-based overheads.
884 1871
885I<create> is the time, in microseconds, to create a single watcher. 1872I<create> is the time, in microseconds (millionths of seconds), that it
1873takes to create a single watcher. The callback is a closure shared between
1874all watchers, to avoid adding memory overhead. That means closure creation
1875and memory usage is not included in the figures.
886 1876
887I<invoke> is the time, in microseconds, used to invoke a simple callback 1877I<invoke> is the time, in microseconds, used to invoke a simple
888that simply counts down. 1878callback. The callback simply counts down a Perl variable and after it was
1879invoked "watcher" times, it would C<< ->send >> a condvar once to
1880signal the end of this phase.
889 1881
890I<destroy> is the time, in microseconds, to destroy a single watcher. 1882I<destroy> is the time, in microseconds, that it takes to destroy a single
1883watcher.
891 1884
1885=head3 Results
1886
892 name watcher bytes create invoke destroy comment 1887 name watchers bytes create invoke destroy comment
893 EV/EV 400000 244 0.56 0.46 0.31 EV native interface 1888 EV/EV 400000 224 0.47 0.35 0.27 EV native interface
894 EV/Any 100000 610 3.52 0.91 0.75 1889 EV/Any 100000 224 2.88 0.34 0.27 EV + AnyEvent watchers
895 CoroEV/Any 100000 610 3.49 0.92 0.75 coroutines + Coro::Signal 1890 CoroEV/Any 100000 224 2.85 0.35 0.28 coroutines + Coro::Signal
896 Perl/Any 10000 654 4.64 1.22 0.77 pure perl implementation 1891 Perl/Any 100000 452 4.13 0.73 0.95 pure perl implementation
897 Event/Event 10000 523 28.05 21.38 5.22 Event native interface 1892 Event/Event 16000 517 32.20 31.80 0.81 Event native interface
898 Event/Any 10000 943 34.43 20.48 1.39 1893 Event/Any 16000 590 35.85 31.55 1.06 Event + AnyEvent watchers
1894 IOAsync/Any 16000 989 38.10 32.77 11.13 via IO::Async::Loop::IO_Poll
1895 IOAsync/Any 16000 990 37.59 29.50 10.61 via IO::Async::Loop::Epoll
899 Glib/Any 16000 1357 96.99 12.55 55.51 quadratic behaviour 1896 Glib/Any 16000 1357 102.33 12.31 51.00 quadratic behaviour
900 Tk/Any 2000 1855 27.01 66.61 14.03 SEGV with >> 2000 watchers 1897 Tk/Any 2000 1860 27.20 66.31 14.00 SEGV with >> 2000 watchers
901 POE/Select 2000 6343 94.69 807.65 562.69 POE::Loop::Select
902 POE/Event 2000 6644 108.15 768.19 14.33 POE::Loop::Event 1898 POE/Event 2000 6328 109.99 751.67 14.02 via POE::Loop::Event
1899 POE/Select 2000 6027 94.54 809.13 579.80 via POE::Loop::Select
903 1900
904Discussion: The benchmark does I<not> bench scalability of the 1901=head3 Discussion
1902
1903The benchmark does I<not> measure scalability of the event loop very
905backend. For example a select-based backend (such as the pureperl one) can 1904well. For example, a select-based event loop (such as the pure perl one)
906never compete with a backend using epoll. In this benchmark, only a single 1905can never compete with an event loop that uses epoll when the number of
907filehandle is used. 1906file descriptors grows high. In this benchmark, all events become ready at
1907the same time, so select/poll-based implementations get an unnatural speed
1908boost.
908 1909
1910Also, note that the number of watchers usually has a nonlinear effect on
1911overall speed, that is, creating twice as many watchers doesn't take twice
1912the time - usually it takes longer. This puts event loops tested with a
1913higher number of watchers at a disadvantage.
1914
1915To put the range of results into perspective, consider that on the
1916benchmark machine, handling an event takes roughly 1600 CPU cycles with
1917EV, 3100 CPU cycles with AnyEvent's pure perl loop and almost 3000000 CPU
1918cycles with POE.
1919
909EV is the sole leader regarding speed and memory use, which are both 1920C<EV> is the sole leader regarding speed and memory use, which are both
910maximal/minimal. Even when going through AnyEvent, there is only one event 1921maximal/minimal, respectively. Even when going through AnyEvent, it uses
911loop that uses less memory (the Event module natively), and no faster 1922far less memory than any other event loop and is still faster than Event
912event model. 1923natively.
913 1924
914The pure perl implementation is hit in a few sweet spots (both the 1925The pure perl implementation is hit in a few sweet spots (both the
915zero timeout and the use of a single fd hit optimisations in the perl 1926constant timeout and the use of a single fd hit optimisations in the perl
916interpreter and the backend itself), but it shows that it adds very little 1927interpreter and the backend itself). Nevertheless this shows that it
917overhead in itself. Like any select-based backend it's performance becomes 1928adds very little overhead in itself. Like any select-based backend its
918really bad with lots of file descriptors. 1929performance becomes really bad with lots of file descriptors (and few of
1930them active), of course, but this was not subject of this benchmark.
919 1931
920The Event module has a relatively high setup and callback invocation cost, 1932The C<Event> module has a relatively high setup and callback invocation
921but overall scores on the third place. 1933cost, but overall scores in on the third place.
922 1934
923Glib has a little higher memory cost, a bit fster callback invocation and 1935C<IO::Async> performs admirably well, about on par with C<Event>, even
924has a similar speed as Event. 1936when using its pure perl backend.
925 1937
1938C<Glib>'s memory usage is quite a bit higher, but it features a
1939faster callback invocation and overall ends up in the same class as
1940C<Event>. However, Glib scales extremely badly, doubling the number of
1941watchers increases the processing time by more than a factor of four,
1942making it completely unusable when using larger numbers of watchers
1943(note that only a single file descriptor was used in the benchmark, so
1944inefficiencies of C<poll> do not account for this).
1945
926The Tk backend works relatively well, the fact that it crashes with 1946The C<Tk> adaptor works relatively well. The fact that it crashes with
927more than 2000 watchers is a big setback, however, as correctness takes 1947more than 2000 watchers is a big setback, however, as correctness takes
928precedence over speed. 1948precedence over speed. Nevertheless, its performance is surprising, as the
1949file descriptor is dup()ed for each watcher. This shows that the dup()
1950employed by some adaptors is not a big performance issue (it does incur a
1951hidden memory cost inside the kernel which is not reflected in the figures
1952above).
929 1953
930POE, regardless of backend (wether it's pure perl select backend or the 1954C<POE>, regardless of underlying event loop (whether using its pure perl
931Event backend) shows abysmal performance and memory usage: Watchers use 1955select-based backend or the Event module, the POE-EV backend couldn't
932almost 30 times as much memory as EV watchers, and 10 times as much memory 1956be tested because it wasn't working) shows abysmal performance and
933as both Event or EV via AnyEvent. 1957memory usage with AnyEvent: Watchers use almost 30 times as much memory
1958as EV watchers, and 10 times as much memory as Event (the high memory
1959requirements are caused by requiring a session for each watcher). Watcher
1960invocation speed is almost 900 times slower than with AnyEvent's pure perl
1961implementation.
934 1962
1963The design of the POE adaptor class in AnyEvent can not really account
1964for the performance issues, though, as session creation overhead is
1965small compared to execution of the state machine, which is coded pretty
1966optimally within L<AnyEvent::Impl::POE> (and while everybody agrees that
1967using multiple sessions is not a good approach, especially regarding
1968memory usage, even the author of POE could not come up with a faster
1969design).
1970
1971=head3 Summary
1972
1973=over 4
1974
935Summary: using EV through AnyEvent is faster than any other event 1975=item * Using EV through AnyEvent is faster than any other event loop
936loop. The overhead AnyEvent adds can be very small, and you should avoid 1976(even when used without AnyEvent), but most event loops have acceptable
937POE like the plague if you want performance or reasonable memory usage. 1977performance with or without AnyEvent.
1978
1979=item * The overhead AnyEvent adds is usually much smaller than the overhead of
1980the actual event loop, only with extremely fast event loops such as EV
1981adds AnyEvent significant overhead.
1982
1983=item * You should avoid POE like the plague if you want performance or
1984reasonable memory usage.
1985
1986=back
1987
1988=head2 BENCHMARKING THE LARGE SERVER CASE
1989
1990This benchmark actually benchmarks the event loop itself. It works by
1991creating a number of "servers": each server consists of a socket pair, a
1992timeout watcher that gets reset on activity (but never fires), and an I/O
1993watcher waiting for input on one side of the socket. Each time the socket
1994watcher reads a byte it will write that byte to a random other "server".
1995
1996The effect is that there will be a lot of I/O watchers, only part of which
1997are active at any one point (so there is a constant number of active
1998fds for each loop iteration, but which fds these are is random). The
1999timeout is reset each time something is read because that reflects how
2000most timeouts work (and puts extra pressure on the event loops).
2001
2002In this benchmark, we use 10000 socket pairs (20000 sockets), of which 100
2003(1%) are active. This mirrors the activity of large servers with many
2004connections, most of which are idle at any one point in time.
2005
2006Source code for this benchmark is found as F<eg/bench2> in the AnyEvent
2007distribution.
2008
2009=head3 Explanation of the columns
2010
2011I<sockets> is the number of sockets, and twice the number of "servers" (as
2012each server has a read and write socket end).
2013
2014I<create> is the time it takes to create a socket pair (which is
2015nontrivial) and two watchers: an I/O watcher and a timeout watcher.
2016
2017I<request>, the most important value, is the time it takes to handle a
2018single "request", that is, reading the token from the pipe and forwarding
2019it to another server. This includes deleting the old timeout and creating
2020a new one that moves the timeout into the future.
2021
2022=head3 Results
2023
2024 name sockets create request
2025 EV 20000 69.01 11.16
2026 Perl 20000 73.32 35.87
2027 IOAsync 20000 157.00 98.14 epoll
2028 IOAsync 20000 159.31 616.06 poll
2029 Event 20000 212.62 257.32
2030 Glib 20000 651.16 1896.30
2031 POE 20000 349.67 12317.24 uses POE::Loop::Event
2032
2033=head3 Discussion
2034
2035This benchmark I<does> measure scalability and overall performance of the
2036particular event loop.
2037
2038EV is again fastest. Since it is using epoll on my system, the setup time
2039is relatively high, though.
2040
2041Perl surprisingly comes second. It is much faster than the C-based event
2042loops Event and Glib.
2043
2044IO::Async performs very well when using its epoll backend, and still quite
2045good compared to Glib when using its pure perl backend.
2046
2047Event suffers from high setup time as well (look at its code and you will
2048understand why). Callback invocation also has a high overhead compared to
2049the C<< $_->() for .. >>-style loop that the Perl event loop uses. Event
2050uses select or poll in basically all documented configurations.
2051
2052Glib is hit hard by its quadratic behaviour w.r.t. many watchers. It
2053clearly fails to perform with many filehandles or in busy servers.
2054
2055POE is still completely out of the picture, taking over 1000 times as long
2056as EV, and over 100 times as long as the Perl implementation, even though
2057it uses a C-based event loop in this case.
2058
2059=head3 Summary
2060
2061=over 4
2062
2063=item * The pure perl implementation performs extremely well.
2064
2065=item * Avoid Glib or POE in large projects where performance matters.
2066
2067=back
2068
2069=head2 BENCHMARKING SMALL SERVERS
2070
2071While event loops should scale (and select-based ones do not...) even to
2072large servers, most programs we (or I :) actually write have only a few
2073I/O watchers.
2074
2075In this benchmark, I use the same benchmark program as in the large server
2076case, but it uses only eight "servers", of which three are active at any
2077one time. This should reflect performance for a small server relatively
2078well.
2079
2080The columns are identical to the previous table.
2081
2082=head3 Results
2083
2084 name sockets create request
2085 EV 16 20.00 6.54
2086 Perl 16 25.75 12.62
2087 Event 16 81.27 35.86
2088 Glib 16 32.63 15.48
2089 POE 16 261.87 276.28 uses POE::Loop::Event
2090
2091=head3 Discussion
2092
2093The benchmark tries to test the performance of a typical small
2094server. While knowing how various event loops perform is interesting, keep
2095in mind that their overhead in this case is usually not as important, due
2096to the small absolute number of watchers (that is, you need efficiency and
2097speed most when you have lots of watchers, not when you only have a few of
2098them).
2099
2100EV is again fastest.
2101
2102Perl again comes second. It is noticeably faster than the C-based event
2103loops Event and Glib, although the difference is too small to really
2104matter.
2105
2106POE also performs much better in this case, but is is still far behind the
2107others.
2108
2109=head3 Summary
2110
2111=over 4
2112
2113=item * C-based event loops perform very well with small number of
2114watchers, as the management overhead dominates.
2115
2116=back
2117
2118=head2 THE IO::Lambda BENCHMARK
2119
2120Recently I was told about the benchmark in the IO::Lambda manpage, which
2121could be misinterpreted to make AnyEvent look bad. In fact, the benchmark
2122simply compares IO::Lambda with POE, and IO::Lambda looks better (which
2123shouldn't come as a surprise to anybody). As such, the benchmark is
2124fine, and mostly shows that the AnyEvent backend from IO::Lambda isn't
2125very optimal. But how would AnyEvent compare when used without the extra
2126baggage? To explore this, I wrote the equivalent benchmark for AnyEvent.
2127
2128The benchmark itself creates an echo-server, and then, for 500 times,
2129connects to the echo server, sends a line, waits for the reply, and then
2130creates the next connection. This is a rather bad benchmark, as it doesn't
2131test the efficiency of the framework or much non-blocking I/O, but it is a
2132benchmark nevertheless.
2133
2134 name runtime
2135 Lambda/select 0.330 sec
2136 + optimized 0.122 sec
2137 Lambda/AnyEvent 0.327 sec
2138 + optimized 0.138 sec
2139 Raw sockets/select 0.077 sec
2140 POE/select, components 0.662 sec
2141 POE/select, raw sockets 0.226 sec
2142 POE/select, optimized 0.404 sec
2143
2144 AnyEvent/select/nb 0.085 sec
2145 AnyEvent/EV/nb 0.068 sec
2146 +state machine 0.134 sec
2147
2148The benchmark is also a bit unfair (my fault): the IO::Lambda/POE
2149benchmarks actually make blocking connects and use 100% blocking I/O,
2150defeating the purpose of an event-based solution. All of the newly
2151written AnyEvent benchmarks use 100% non-blocking connects (using
2152AnyEvent::Socket::tcp_connect and the asynchronous pure perl DNS
2153resolver), so AnyEvent is at a disadvantage here, as non-blocking connects
2154generally require a lot more bookkeeping and event handling than blocking
2155connects (which involve a single syscall only).
2156
2157The last AnyEvent benchmark additionally uses L<AnyEvent::Handle>, which
2158offers similar expressive power as POE and IO::Lambda, using conventional
2159Perl syntax. This means that both the echo server and the client are 100%
2160non-blocking, further placing it at a disadvantage.
2161
2162As you can see, the AnyEvent + EV combination even beats the
2163hand-optimised "raw sockets benchmark", while AnyEvent + its pure perl
2164backend easily beats IO::Lambda and POE.
2165
2166And even the 100% non-blocking version written using the high-level (and
2167slow :) L<AnyEvent::Handle> abstraction beats both POE and IO::Lambda by a
2168large margin, even though it does all of DNS, tcp-connect and socket I/O
2169in a non-blocking way.
2170
2171The two AnyEvent benchmarks programs can be found as F<eg/ae0.pl> and
2172F<eg/ae2.pl> in the AnyEvent distribution, the remaining benchmarks are
2173part of the IO::lambda distribution and were used without any changes.
2174
2175
2176=head1 SIGNALS
2177
2178AnyEvent currently installs handlers for these signals:
2179
2180=over 4
2181
2182=item SIGCHLD
2183
2184A handler for C<SIGCHLD> is installed by AnyEvent's child watcher
2185emulation for event loops that do not support them natively. Also, some
2186event loops install a similar handler.
2187
2188Additionally, when AnyEvent is loaded and SIGCHLD is set to IGNORE, then
2189AnyEvent will reset it to default, to avoid losing child exit statuses.
2190
2191=item SIGPIPE
2192
2193A no-op handler is installed for C<SIGPIPE> when C<$SIG{PIPE}> is C<undef>
2194when AnyEvent gets loaded.
2195
2196The rationale for this is that AnyEvent users usually do not really depend
2197on SIGPIPE delivery (which is purely an optimisation for shell use, or
2198badly-written programs), but C<SIGPIPE> can cause spurious and rare
2199program exits as a lot of people do not expect C<SIGPIPE> when writing to
2200some random socket.
2201
2202The rationale for installing a no-op handler as opposed to ignoring it is
2203that this way, the handler will be restored to defaults on exec.
2204
2205Feel free to install your own handler, or reset it to defaults.
2206
2207=back
2208
2209=cut
2210
2211undef $SIG{CHLD}
2212 if $SIG{CHLD} eq 'IGNORE';
2213
2214$SIG{PIPE} = sub { }
2215 unless defined $SIG{PIPE};
2216
2217=head1 RECOMMENDED/OPTIONAL MODULES
2218
2219One of AnyEvent's main goals is to be 100% Pure-Perl(tm): only perl (and
2220it's built-in modules) are required to use it.
2221
2222That does not mean that AnyEvent won't take advantage of some additional
2223modules if they are installed.
2224
2225This section epxlains which additional modules will be used, and how they
2226affect AnyEvent's operetion.
2227
2228=over 4
2229
2230=item L<Async::Interrupt>
2231
2232This slightly arcane module is used to implement fast signal handling: To
2233my knowledge, there is no way to do completely race-free and quick
2234signal handling in pure perl. To ensure that signals still get
2235delivered, AnyEvent will start an interval timer to wake up perl (and
2236catch the signals) with soemd elay (default is 10 seconds, look for
2237C<$AnyEvent::MAX_SIGNAL_LATENCY>).
2238
2239If this module is available, then it will be used to implement signal
2240catching, which means that signals will not be delayed, and the event loop
2241will not be interrupted regularly, which is more efficient (And good for
2242battery life on laptops).
2243
2244This affects not just the pure-perl event loop, but also other event loops
2245that have no signal handling on their own (e.g. Glib, Tk, Qt).
2246
2247=item L<EV>
2248
2249This module isn't really "optional", as it is simply one of the backend
2250event loops that AnyEvent can use. However, it is simply the best event
2251loop available in terms of features, speed and stability: It supports
2252the AnyEvent API optimally, implements all the watcher types in XS, does
2253automatic timer adjustments even when no monotonic clock is available,
2254can take avdantage of advanced kernel interfaces such as C<epoll> and
2255C<kqueue>, and is the fastest backend I<by far>. You can even embed
2256L<Glib>/L<Gtk2> in it (or vice versa, see L<EV::Glib> and L<Glib::EV>).
2257
2258=item L<Guard>
2259
2260The guard module, when used, will be used to implement
2261C<AnyEvent::Util::guard>. This speeds up guards considerably (and uses a
2262lot less memory), but otherwise doesn't affect guard operation much. It is
2263purely used for performance.
2264
2265=item L<JSON> and L<JSON::XS>
2266
2267This module is required when you want to read or write JSON data via
2268L<AnyEvent::Handle>. It is also written in pure-perl, but can take
2269advantage of the ulta-high-speed L<JSON::XS> module when it is installed.
2270
2271In fact, L<AnyEvent::Handle> will use L<JSON::XS> by default if it is
2272installed.
2273
2274=item L<Net::SSLeay>
2275
2276Implementing TLS/SSL in Perl is certainly interesting, but not very
2277worthwhile: If this module is installed, then L<AnyEvent::Handle> (with
2278the help of L<AnyEvent::TLS>), gains the ability to do TLS/SSL.
2279
2280=item L<Time::HiRes>
2281
2282This module is part of perl since release 5.008. It will be used when the
2283chosen event library does not come with a timing source on it's own. The
2284pure-perl event loop (L<AnyEvent::Impl::Perl>) will additionally use it to
2285try to use a monotonic clock for timing stability.
2286
2287=back
938 2288
939 2289
940=head1 FORK 2290=head1 FORK
941 2291
942Most event libraries are not fork-safe. The ones who are usually are 2292Most event libraries are not fork-safe. The ones who are usually are
943because they are so inefficient. Only L<EV> is fully fork-aware. 2293because they rely on inefficient but fork-safe C<select> or C<poll>
2294calls. Only L<EV> is fully fork-aware.
944 2295
945If you have to fork, you must either do so I<before> creating your first 2296If you have to fork, you must either do so I<before> creating your first
946watcher OR you must not use AnyEvent at all in the child. 2297watcher OR you must not use AnyEvent at all in the child OR you must do
2298something completely out of the scope of AnyEvent.
947 2299
948 2300
949=head1 SECURITY CONSIDERATIONS 2301=head1 SECURITY CONSIDERATIONS
950 2302
951AnyEvent can be forced to load any event model via 2303AnyEvent can be forced to load any event model via
956specified in the variable. 2308specified in the variable.
957 2309
958You can make AnyEvent completely ignore this variable by deleting it 2310You can make AnyEvent completely ignore this variable by deleting it
959before the first watcher gets created, e.g. with a C<BEGIN> block: 2311before the first watcher gets created, e.g. with a C<BEGIN> block:
960 2312
961 BEGIN { delete $ENV{PERL_ANYEVENT_MODEL} } 2313 BEGIN { delete $ENV{PERL_ANYEVENT_MODEL} }
962 2314
963 use AnyEvent; 2315 use AnyEvent;
2316
2317Similar considerations apply to $ENV{PERL_ANYEVENT_VERBOSE}, as that can
2318be used to probe what backend is used and gain other information (which is
2319probably even less useful to an attacker than PERL_ANYEVENT_MODEL), and
2320$ENV{PERL_ANYEVENT_STRICT}.
2321
2322Note that AnyEvent will remove I<all> environment variables starting with
2323C<PERL_ANYEVENT_> from C<%ENV> when it is loaded while taint mode is
2324enabled.
2325
2326
2327=head1 BUGS
2328
2329Perl 5.8 has numerous memleaks that sometimes hit this module and are hard
2330to work around. If you suffer from memleaks, first upgrade to Perl 5.10
2331and check wether the leaks still show up. (Perl 5.10.0 has other annoying
2332memleaks, such as leaking on C<map> and C<grep> but it is usually not as
2333pronounced).
964 2334
965 2335
966=head1 SEE ALSO 2336=head1 SEE ALSO
967 2337
968Event modules: L<Coro::EV>, L<EV>, L<EV::Glib>, L<Glib::EV>, 2338Utility functions: L<AnyEvent::Util>.
969L<Coro::Event>, L<Event>, L<Glib::Event>, L<Glib>, L<Coro>, L<Tk>, 2339
2340Event modules: L<EV>, L<EV::Glib>, L<Glib::EV>, L<Event>, L<Glib::Event>,
970L<Event::Lib>, L<Qt>, L<POE>. 2341L<Glib>, L<Tk>, L<Event::Lib>, L<Qt>, L<POE>.
971 2342
972Implementations: L<AnyEvent::Impl::CoroEV>, L<AnyEvent::Impl::EV>, 2343Implementations: L<AnyEvent::Impl::EV>, L<AnyEvent::Impl::Event>,
973L<AnyEvent::Impl::CoroEvent>, L<AnyEvent::Impl::Event>, L<AnyEvent::Impl::Glib>, 2344L<AnyEvent::Impl::Glib>, L<AnyEvent::Impl::Tk>, L<AnyEvent::Impl::Perl>,
974L<AnyEvent::Impl::Tk>, L<AnyEvent::Impl::Perl>, L<AnyEvent::Impl::EventLib>, 2345L<AnyEvent::Impl::EventLib>, L<AnyEvent::Impl::Qt>,
975L<AnyEvent::Impl::Qt>, L<AnyEvent::Impl::POE>. 2346L<AnyEvent::Impl::POE>, L<AnyEvent::Impl::IOAsync>.
976 2347
2348Non-blocking file handles, sockets, TCP clients and
2349servers: L<AnyEvent::Handle>, L<AnyEvent::Socket>, L<AnyEvent::TLS>.
2350
2351Asynchronous DNS: L<AnyEvent::DNS>.
2352
2353Coroutine support: L<Coro>, L<Coro::AnyEvent>, L<Coro::EV>,
2354L<Coro::Event>,
2355
977Nontrivial usage examples: L<Net::FCP>, L<Net::XMPP2>. 2356Nontrivial usage examples: L<AnyEvent::GPSD>, L<AnyEvent::XMPP>,
2357L<AnyEvent::HTTP>.
978 2358
979 2359
980=head1 AUTHOR 2360=head1 AUTHOR
981 2361
982 Marc Lehmann <schmorp@schmorp.de> 2362 Marc Lehmann <schmorp@schmorp.de>
983 http://home.schmorp.de/ 2363 http://home.schmorp.de/
984 2364
985=cut 2365=cut
986 2366
9871 23671
988 2368

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines