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.77 by root, Fri Apr 25 09:00:37 2008 UTC vs.
Revision 1.244 by root, Fri Jul 17 23:15:57 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
1046# basically a tuned-down version of common::sense
1047sub common_sense {
434no warnings; 1048 # no warnings
435use strict; 1049 ${^WARNING_BITS} ^= ${^WARNING_BITS};
1050 # use strict vars subs
1051 $^H |= 0x00000600;
1052}
436 1053
1054BEGIN { AnyEvent::common_sense }
1055
437use Carp; 1056use Carp ();
438 1057
439our $VERSION = '3.3'; 1058our $VERSION = 4.83;
440our $MODEL; 1059our $MODEL;
441 1060
442our $AUTOLOAD; 1061our $AUTOLOAD;
443our @ISA; 1062our @ISA;
444 1063
445our $verbose = $ENV{PERL_ANYEVENT_VERBOSE}*1;
446
447our @REGISTRY; 1064our @REGISTRY;
448 1065
1066our $WIN32;
1067
1068our $VERBOSE;
1069
1070BEGIN {
1071 eval "sub WIN32(){ " . (($^O =~ /mswin32/i)*1) ." }";
1072 eval "sub TAINT(){ " . (${^TAINT}*1) . " }";
1073
1074 delete @ENV{grep /^PERL_ANYEVENT_/, keys %ENV}
1075 if ${^TAINT};
1076
1077 $VERBOSE = $ENV{PERL_ANYEVENT_VERBOSE}*1;
1078
1079}
1080
1081our $MAX_SIGNAL_LATENCY = 10;
1082
1083our %PROTOCOL; # (ipv4|ipv6) => (1|2), higher numbers are preferred
1084
1085{
1086 my $idx;
1087 $PROTOCOL{$_} = ++$idx
1088 for reverse split /\s*,\s*/,
1089 $ENV{PERL_ANYEVENT_PROTOCOLS} || "ipv4,ipv6";
1090}
1091
449my @models = ( 1092my @models = (
450 [Coro::EV:: => AnyEvent::Impl::CoroEV::],
451 [Coro::Event:: => AnyEvent::Impl::CoroEvent::],
452 [EV:: => AnyEvent::Impl::EV::], 1093 [EV:: => AnyEvent::Impl::EV::],
453 [Event:: => AnyEvent::Impl::Event::], 1094 [Event:: => AnyEvent::Impl::Event::],
454 [Glib:: => AnyEvent::Impl::Glib::], 1095 [AnyEvent::Impl::Perl:: => AnyEvent::Impl::Perl::],
1096 # everything below here will not be autoprobed
1097 # as the pureperl backend should work everywhere
1098 # and is usually faster
1099 [Glib:: => AnyEvent::Impl::Glib::], # becomes extremely slow with many watchers
1100 [Event::Lib:: => AnyEvent::Impl::EventLib::], # too buggy
455 [Tk:: => AnyEvent::Impl::Tk::], 1101 [Tk:: => AnyEvent::Impl::Tk::], # crashes with many handles
1102 [Qt:: => AnyEvent::Impl::Qt::], # requires special main program
1103 [POE::Kernel:: => AnyEvent::Impl::POE::], # lasciate ogni speranza
456 [Wx:: => AnyEvent::Impl::POE::], 1104 [Wx:: => AnyEvent::Impl::POE::],
457 [Prima:: => AnyEvent::Impl::POE::], 1105 [Prima:: => AnyEvent::Impl::POE::],
458 [AnyEvent::Impl::Perl:: => AnyEvent::Impl::Perl::], 1106 # 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 1107 # byzantine signal and broken child handling, among others.
460 [Event::Lib:: => AnyEvent::Impl::EventLib::], # too buggy 1108 # IO::Async is rather hard to detect, as it doesn't have any
1109 # obvious default class.
461 [Qt:: => AnyEvent::Impl::Qt::], # requires special main program 1110# [IO::Async:: => AnyEvent::Impl::IOAsync::], # requires special main program
462 [POE::Kernel:: => AnyEvent::Impl::POE::], # lasciate ogni speranza 1111# [IO::Async::Loop:: => AnyEvent::Impl::IOAsync::], # requires special main program
1112# [IO::Async::Notifier:: => AnyEvent::Impl::IOAsync::], # requires special main program
463); 1113);
464 1114
465our %method = map +($_ => 1), qw(io timer signal child condvar broadcast wait one_event DESTROY); 1115our %method = map +($_ => 1),
1116 qw(io timer time now now_update signal child idle condvar one_event DESTROY);
1117
1118our @post_detect;
1119
1120sub post_detect(&) {
1121 my ($cb) = @_;
1122
1123 if ($MODEL) {
1124 $cb->();
1125
1126 1
1127 } else {
1128 push @post_detect, $cb;
1129
1130 defined wantarray
1131 ? bless \$cb, "AnyEvent::Util::postdetect"
1132 : ()
1133 }
1134}
1135
1136sub AnyEvent::Util::postdetect::DESTROY {
1137 @post_detect = grep $_ != ${$_[0]}, @post_detect;
1138}
466 1139
467sub detect() { 1140sub detect() {
468 unless ($MODEL) { 1141 unless ($MODEL) {
469 no strict 'refs'; 1142 local $SIG{__DIE__};
470 1143
471 if ($ENV{PERL_ANYEVENT_MODEL} =~ /^([a-zA-Z]+)$/) { 1144 if ($ENV{PERL_ANYEVENT_MODEL} =~ /^([a-zA-Z]+)$/) {
472 my $model = "AnyEvent::Impl::$1"; 1145 my $model = "AnyEvent::Impl::$1";
473 if (eval "require $model") { 1146 if (eval "require $model") {
474 $MODEL = $model; 1147 $MODEL = $model;
475 warn "AnyEvent: loaded model '$model' (forced by \$PERL_ANYEVENT_MODEL), using it.\n" if $verbose > 1; 1148 warn "AnyEvent: loaded model '$model' (forced by \$ENV{PERL_ANYEVENT_MODEL}), using it.\n" if $VERBOSE >= 2;
476 } else { 1149 } else {
477 warn "AnyEvent: unable to load model '$model' (from \$PERL_ANYEVENT_MODEL):\n$@" if $verbose; 1150 warn "AnyEvent: unable to load model '$model' (from \$ENV{PERL_ANYEVENT_MODEL}):\n$@" if $VERBOSE;
478 } 1151 }
479 } 1152 }
480 1153
481 # check for already loaded models 1154 # check for already loaded models
482 unless ($MODEL) { 1155 unless ($MODEL) {
483 for (@REGISTRY, @models) { 1156 for (@REGISTRY, @models) {
484 my ($package, $model) = @$_; 1157 my ($package, $model) = @$_;
485 if (${"$package\::VERSION"} > 0) { 1158 if (${"$package\::VERSION"} > 0) {
486 if (eval "require $model") { 1159 if (eval "require $model") {
487 $MODEL = $model; 1160 $MODEL = $model;
488 warn "AnyEvent: autodetected model '$model', using it.\n" if $verbose > 1; 1161 warn "AnyEvent: autodetected model '$model', using it.\n" if $VERBOSE >= 2;
489 last; 1162 last;
490 } 1163 }
491 } 1164 }
492 } 1165 }
493 1166
498 my ($package, $model) = @$_; 1171 my ($package, $model) = @$_;
499 if (eval "require $package" 1172 if (eval "require $package"
500 and ${"$package\::VERSION"} > 0 1173 and ${"$package\::VERSION"} > 0
501 and eval "require $model") { 1174 and eval "require $model") {
502 $MODEL = $model; 1175 $MODEL = $model;
503 warn "AnyEvent: autoprobed model '$model', using it.\n" if $verbose > 1; 1176 warn "AnyEvent: autoprobed model '$model', using it.\n" if $VERBOSE >= 2;
504 last; 1177 last;
505 } 1178 }
506 } 1179 }
507 1180
508 $MODEL 1181 $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."; 1182 or die "No event module selected for AnyEvent and autodetect failed. Install any one of these modules: EV, Event or Glib.\n";
510 } 1183 }
511 } 1184 }
512 1185
1186 push @{"$MODEL\::ISA"}, "AnyEvent::Base";
1187
513 unshift @ISA, $MODEL; 1188 unshift @ISA, $MODEL;
514 push @{"$MODEL\::ISA"}, "AnyEvent::Base"; 1189
1190 require AnyEvent::Strict if $ENV{PERL_ANYEVENT_STRICT};
1191
1192 (shift @post_detect)->() while @post_detect;
515 } 1193 }
516 1194
517 $MODEL 1195 $MODEL
518} 1196}
519 1197
520sub AUTOLOAD { 1198sub AUTOLOAD {
521 (my $func = $AUTOLOAD) =~ s/.*://; 1199 (my $func = $AUTOLOAD) =~ s/.*://;
522 1200
523 $method{$func} 1201 $method{$func}
524 or croak "$func: not a valid method for AnyEvent objects"; 1202 or Carp::croak "$func: not a valid method for AnyEvent objects";
525 1203
526 detect unless $MODEL; 1204 detect unless $MODEL;
527 1205
528 my $class = shift; 1206 my $class = shift;
529 $class->$func (@_); 1207 $class->$func (@_);
530} 1208}
531 1209
1210# utility function to dup a filehandle. this is used by many backends
1211# to support binding more than one watcher per filehandle (they usually
1212# allow only one watcher per fd, so we dup it to get a different one).
1213sub _dupfh($$;$$) {
1214 my ($poll, $fh, $r, $w) = @_;
1215
1216 # cygwin requires the fh mode to be matching, unix doesn't
1217 my ($rw, $mode) = $poll eq "r" ? ($r, "<&") : ($w, ">&");
1218
1219 open my $fh2, $mode, $fh
1220 or die "AnyEvent->io: cannot dup() filehandle in mode '$poll': $!,";
1221
1222 # we assume CLOEXEC is already set by perl in all important cases
1223
1224 ($fh2, $rw)
1225}
1226
532package AnyEvent::Base; 1227package AnyEvent::Base;
533 1228
1229# default implementations for many methods
1230
1231sub _time {
1232 # probe for availability of Time::HiRes
1233 if (eval "use Time::HiRes (); Time::HiRes::time (); 1") {
1234 warn "AnyEvent: using Time::HiRes for sub-second timing accuracy.\n" if $VERBOSE >= 8;
1235 *_time = \&Time::HiRes::time;
1236 # if (eval "use POSIX (); (POSIX::times())...
1237 } else {
1238 warn "AnyEvent: using built-in time(), WARNING, no sub-second resolution!\n" if $VERBOSE;
1239 *_time = sub { time }; # epic fail
1240 }
1241
1242 &_time
1243}
1244
1245sub time { _time }
1246sub now { _time }
1247sub now_update { }
1248
534# default implementation for ->condvar, ->wait, ->broadcast 1249# default implementation for ->condvar
535 1250
536sub condvar { 1251sub condvar {
537 bless \my $flag, "AnyEvent::Base::CondVar" 1252 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} 1253}
547 1254
548# default implementation for ->signal 1255# default implementation for ->signal
549 1256
550our %SIG_CB; 1257our $HAVE_ASYNC_INTERRUPT;
1258our ($SIGPIPE_R, $SIGPIPE_W, %SIG_CB, %SIG_EV, $SIG_IO);
1259our (%SIG_ASY, %SIG_ASY_W);
1260our ($SIG_COUNT, $SIG_TW);
551 1261
1262sub _signal_exec {
1263 $HAVE_ASYNC_INTERRUPT
1264 ? $SIGPIPE_R->drain
1265 : sysread $SIGPIPE_R, my $dummy, 9;
1266
1267 while (%SIG_EV) {
1268 for (keys %SIG_EV) {
1269 delete $SIG_EV{$_};
1270 $_->() for values %{ $SIG_CB{$_} || {} };
1271 }
1272 }
1273}
1274
552sub signal { 1275sub _signal {
553 my (undef, %arg) = @_; 1276 my (undef, %arg) = @_;
554 1277
555 my $signal = uc $arg{signal} 1278 my $signal = uc $arg{signal}
556 or Carp::croak "required option 'signal' is missing"; 1279 or Carp::croak "required option 'signal' is missing";
557 1280
558 $SIG_CB{$signal}{$arg{cb}} = $arg{cb}; 1281 $SIG_CB{$signal}{$arg{cb}} = $arg{cb};
1282
1283 if ($HAVE_ASYNC_INTERRUPT) {
1284 # async::interrupt
1285
1286 $SIG_ASY{$signal} ||= do {
1287 my $asy = new Async::Interrupt
1288 cb => sub { undef $SIG_EV{$signal} },
1289 signal => $signal,
1290 pipe => [$SIGPIPE_R->filenos],
1291 ;
1292 $asy->pipe_autodrain (0);
1293
1294 $asy
1295 };
1296
1297 } else {
1298 # pure perl
1299
559 $SIG{$signal} ||= sub { 1300 $SIG{$signal} ||= sub {
560 $_->() for values %{ $SIG_CB{$signal} || {} }; 1301 local $!;
1302 syswrite $SIGPIPE_W, "\x00", 1 unless %SIG_EV;
1303 undef $SIG_EV{$signal};
1304 };
1305
1306 # can't do signal processing without introducing races in pure perl,
1307 # so limit the signal latency.
1308 ++$SIG_COUNT;
1309 $SIG_TW ||= AnyEvent->timer (
1310 after => $MAX_SIGNAL_LATENCY,
1311 interval => $MAX_SIGNAL_LATENCY,
1312 cb => sub { }, # just for the PERL_ASYNC_CHECK
1313 );
561 }; 1314 }
562 1315
563 bless [$signal, $arg{cb}], "AnyEvent::Base::Signal" 1316 bless [$signal, $arg{cb}], "AnyEvent::Base::signal"
564} 1317}
565 1318
1319sub signal {
1320 # probe for availability of Async::Interrupt
1321 if (!$ENV{PERL_ANYEVENT_AVOID_ASYNC_INTERRUPT} && eval "use Async::Interrupt 0.6 (); 1") {
1322 warn "AnyEvent: using Async::Interrupt for race-free signal handling.\n" if $VERBOSE >= 8;
1323
1324 $HAVE_ASYNC_INTERRUPT = 1;
1325 $SIGPIPE_R = new Async::Interrupt::EventPipe;
1326 $SIG_IO = AnyEvent->io (fh => $SIGPIPE_R->fileno, poll => "r", cb => \&_signal_exec);
1327
1328 } else {
1329 warn "AnyEvent: using emulated perl signal handling with latency timer.\n" if $VERBOSE >= 8;
1330
1331 require Fcntl;
1332
1333 if (AnyEvent::WIN32) {
1334 require AnyEvent::Util;
1335
1336 ($SIGPIPE_R, $SIGPIPE_W) = AnyEvent::Util::portable_pipe ();
1337 AnyEvent::Util::fh_nonblocking ($SIGPIPE_R) if $SIGPIPE_R;
1338 AnyEvent::Util::fh_nonblocking ($SIGPIPE_W) if $SIGPIPE_W; # just in case
1339 } else {
1340 pipe $SIGPIPE_R, $SIGPIPE_W;
1341 fcntl $SIGPIPE_R, &Fcntl::F_SETFL, &Fcntl::O_NONBLOCK if $SIGPIPE_R;
1342 fcntl $SIGPIPE_W, &Fcntl::F_SETFL, &Fcntl::O_NONBLOCK if $SIGPIPE_W; # just in case
1343
1344 # not strictly required, as $^F is normally 2, but let's make sure...
1345 fcntl $SIGPIPE_R, &Fcntl::F_SETFD, &Fcntl::FD_CLOEXEC;
1346 fcntl $SIGPIPE_W, &Fcntl::F_SETFD, &Fcntl::FD_CLOEXEC;
1347 }
1348
1349 $SIGPIPE_R
1350 or Carp::croak "AnyEvent: unable to create a signal reporting pipe: $!\n";
1351
1352 $SIG_IO = AnyEvent->io (fh => $SIGPIPE_R, poll => "r", cb => \&_signal_exec);
1353 }
1354
1355 *signal = \&_signal;
1356 &signal
1357}
1358
566sub AnyEvent::Base::Signal::DESTROY { 1359sub AnyEvent::Base::signal::DESTROY {
567 my ($signal, $cb) = @{$_[0]}; 1360 my ($signal, $cb) = @{$_[0]};
568 1361
1362 undef $SIG_TW
1363 unless --$SIG_COUNT;
1364
569 delete $SIG_CB{$signal}{$cb}; 1365 delete $SIG_CB{$signal}{$cb};
570 1366
571 $SIG{$signal} = 'DEFAULT' unless keys %{ $SIG_CB{$signal} }; 1367 # delete doesn't work with older perls - they then
1368 # print weird messages, or just unconditionally exit
1369 # instead of getting the default action.
1370 undef $SIG{$signal}
1371 unless keys %{ $SIG_CB{$signal} };
572} 1372}
573 1373
574# default implementation for ->child 1374# default implementation for ->child
575 1375
576our %PID_CB; 1376our %PID_CB;
577our $CHLD_W; 1377our $CHLD_W;
578our $CHLD_DELAY_W; 1378our $CHLD_DELAY_W;
579our $PID_IDLE;
580our $WNOHANG; 1379our $WNOHANG;
581 1380
582sub _child_wait { 1381sub _sigchld {
583 while (0 < (my $pid = waitpid -1, $WNOHANG)) { 1382 while (0 < (my $pid = waitpid -1, $WNOHANG)) {
1383 $_->($pid, $?)
584 $_->($pid, $?) for (values %{ $PID_CB{$pid} || {} }), 1384 for values %{ $PID_CB{$pid} || {} },
585 (values %{ $PID_CB{0} || {} }); 1385 values %{ $PID_CB{0} || {} };
586 } 1386 }
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} 1387}
598 1388
599sub child { 1389sub child {
600 my (undef, %arg) = @_; 1390 my (undef, %arg) = @_;
601 1391
602 defined (my $pid = $arg{pid} + 0) 1392 defined (my $pid = $arg{pid} + 0)
603 or Carp::croak "required option 'pid' is missing"; 1393 or Carp::croak "required option 'pid' is missing";
604 1394
605 $PID_CB{$pid}{$arg{cb}} = $arg{cb}; 1395 $PID_CB{$pid}{$arg{cb}} = $arg{cb};
606 1396
607 unless ($WNOHANG) { 1397 # WNOHANG is almost cetrainly 1 everywhere
608 $WNOHANG = eval { require POSIX; &POSIX::WNOHANG } || 1; 1398 $WNOHANG ||= $^O =~ /^(?:openbsd|netbsd|linux|freebsd|cygwin|MSWin32)$/
609 } 1399 ? 1
1400 : eval { local $SIG{__DIE__}; require POSIX; &POSIX::WNOHANG } || 1;
610 1401
611 unless ($CHLD_W) { 1402 unless ($CHLD_W) {
612 $CHLD_W = AnyEvent->signal (signal => 'CHLD', cb => \&_sigchld); 1403 $CHLD_W = AnyEvent->signal (signal => 'CHLD', cb => \&_sigchld);
613 # child could be a zombie already, so make at least one round 1404 # child could be a zombie already, so make at least one round
614 &_sigchld; 1405 &_sigchld;
615 } 1406 }
616 1407
617 bless [$pid, $arg{cb}], "AnyEvent::Base::Child" 1408 bless [$pid, $arg{cb}], "AnyEvent::Base::child"
618} 1409}
619 1410
620sub AnyEvent::Base::Child::DESTROY { 1411sub AnyEvent::Base::child::DESTROY {
621 my ($pid, $cb) = @{$_[0]}; 1412 my ($pid, $cb) = @{$_[0]};
622 1413
623 delete $PID_CB{$pid}{$cb}; 1414 delete $PID_CB{$pid}{$cb};
624 delete $PID_CB{$pid} unless keys %{ $PID_CB{$pid} }; 1415 delete $PID_CB{$pid} unless keys %{ $PID_CB{$pid} };
625 1416
626 undef $CHLD_W unless keys %PID_CB; 1417 undef $CHLD_W unless keys %PID_CB;
627} 1418}
1419
1420# idle emulation is done by simply using a timer, regardless
1421# of whether the process is idle or not, and not letting
1422# the callback use more than 50% of the time.
1423sub idle {
1424 my (undef, %arg) = @_;
1425
1426 my ($cb, $w, $rcb) = $arg{cb};
1427
1428 $rcb = sub {
1429 if ($cb) {
1430 $w = _time;
1431 &$cb;
1432 $w = _time - $w;
1433
1434 # never use more then 50% of the time for the idle watcher,
1435 # within some limits
1436 $w = 0.0001 if $w < 0.0001;
1437 $w = 5 if $w > 5;
1438
1439 $w = AnyEvent->timer (after => $w, cb => $rcb);
1440 } else {
1441 # clean up...
1442 undef $w;
1443 undef $rcb;
1444 }
1445 };
1446
1447 $w = AnyEvent->timer (after => 0.05, cb => $rcb);
1448
1449 bless \\$cb, "AnyEvent::Base::idle"
1450}
1451
1452sub AnyEvent::Base::idle::DESTROY {
1453 undef $${$_[0]};
1454}
1455
1456package AnyEvent::CondVar;
1457
1458our @ISA = AnyEvent::CondVar::Base::;
1459
1460package AnyEvent::CondVar::Base;
1461
1462#use overload
1463# '&{}' => sub { my $self = shift; sub { $self->send (@_) } },
1464# fallback => 1;
1465
1466# save 300+ kilobytes by dirtily hardcoding overloading
1467${"AnyEvent::CondVar::Base::OVERLOAD"}{dummy}++; # Register with magic by touching.
1468*{'AnyEvent::CondVar::Base::()'} = sub { }; # "Make it findable via fetchmethod."
1469*{'AnyEvent::CondVar::Base::(&{}'} = sub { my $self = shift; sub { $self->send (@_) } }; # &{}
1470${'AnyEvent::CondVar::Base::()'} = 1; # fallback
1471
1472our $WAITING;
1473
1474sub _send {
1475 # nop
1476}
1477
1478sub send {
1479 my $cv = shift;
1480 $cv->{_ae_sent} = [@_];
1481 (delete $cv->{_ae_cb})->($cv) if $cv->{_ae_cb};
1482 $cv->_send;
1483}
1484
1485sub croak {
1486 $_[0]{_ae_croak} = $_[1];
1487 $_[0]->send;
1488}
1489
1490sub ready {
1491 $_[0]{_ae_sent}
1492}
1493
1494sub _wait {
1495 $WAITING
1496 and !$_[0]{_ae_sent}
1497 and Carp::croak "AnyEvent::CondVar: recursive blocking wait detected";
1498
1499 local $WAITING = 1;
1500 AnyEvent->one_event while !$_[0]{_ae_sent};
1501}
1502
1503sub recv {
1504 $_[0]->_wait;
1505
1506 Carp::croak $_[0]{_ae_croak} if $_[0]{_ae_croak};
1507 wantarray ? @{ $_[0]{_ae_sent} } : $_[0]{_ae_sent}[0]
1508}
1509
1510sub cb {
1511 $_[0]{_ae_cb} = $_[1] if @_ > 1;
1512 $_[0]{_ae_cb}
1513}
1514
1515sub begin {
1516 ++$_[0]{_ae_counter};
1517 $_[0]{_ae_end_cb} = $_[1] if @_ > 1;
1518}
1519
1520sub end {
1521 return if --$_[0]{_ae_counter};
1522 &{ $_[0]{_ae_end_cb} || sub { $_[0]->send } };
1523}
1524
1525# undocumented/compatibility with pre-3.4
1526*broadcast = \&send;
1527*wait = \&_wait;
1528
1529=head1 ERROR AND EXCEPTION HANDLING
1530
1531In general, AnyEvent does not do any error handling - it relies on the
1532caller to do that if required. The L<AnyEvent::Strict> module (see also
1533the C<PERL_ANYEVENT_STRICT> environment variable, below) provides strict
1534checking of all AnyEvent methods, however, which is highly useful during
1535development.
1536
1537As for exception handling (i.e. runtime errors and exceptions thrown while
1538executing a callback), this is not only highly event-loop specific, but
1539also not in any way wrapped by this module, as this is the job of the main
1540program.
1541
1542The pure perl event loop simply re-throws the exception (usually
1543within C<< condvar->recv >>), the L<Event> and L<EV> modules call C<<
1544$Event/EV::DIED->() >>, L<Glib> uses C<< install_exception_handler >> and
1545so on.
1546
1547=head1 ENVIRONMENT VARIABLES
1548
1549The following environment variables are used by this module or its
1550submodules.
1551
1552Note that AnyEvent will remove I<all> environment variables starting with
1553C<PERL_ANYEVENT_> from C<%ENV> when it is loaded while taint mode is
1554enabled.
1555
1556=over 4
1557
1558=item C<PERL_ANYEVENT_VERBOSE>
1559
1560By default, AnyEvent will be completely silent except in fatal
1561conditions. You can set this environment variable to make AnyEvent more
1562talkative.
1563
1564When set to C<1> or higher, causes AnyEvent to warn about unexpected
1565conditions, such as not being able to load the event model specified by
1566C<PERL_ANYEVENT_MODEL>.
1567
1568When set to C<2> or higher, cause AnyEvent to report to STDERR which event
1569model it chooses.
1570
1571When set to C<8> or higher, then AnyEvent will report extra information on
1572which optional modules it loads and how it implements certain features.
1573
1574=item C<PERL_ANYEVENT_STRICT>
1575
1576AnyEvent does not do much argument checking by default, as thorough
1577argument checking is very costly. Setting this variable to a true value
1578will cause AnyEvent to load C<AnyEvent::Strict> and then to thoroughly
1579check the arguments passed to most method calls. If it finds any problems,
1580it will croak.
1581
1582In other words, enables "strict" mode.
1583
1584Unlike C<use strict> (or it's modern cousin, C<< use L<common::sense>
1585>>, it is definitely recommended to keep it off in production. Keeping
1586C<PERL_ANYEVENT_STRICT=1> in your environment while developing programs
1587can be very useful, however.
1588
1589=item C<PERL_ANYEVENT_MODEL>
1590
1591This can be used to specify the event model to be used by AnyEvent, before
1592auto detection and -probing kicks in. It must be a string consisting
1593entirely of ASCII letters. The string C<AnyEvent::Impl::> gets prepended
1594and the resulting module name is loaded and if the load was successful,
1595used as event model. If it fails to load AnyEvent will proceed with
1596auto detection and -probing.
1597
1598This functionality might change in future versions.
1599
1600For example, to force the pure perl model (L<AnyEvent::Impl::Perl>) you
1601could start your program like this:
1602
1603 PERL_ANYEVENT_MODEL=Perl perl ...
1604
1605=item C<PERL_ANYEVENT_PROTOCOLS>
1606
1607Used by both L<AnyEvent::DNS> and L<AnyEvent::Socket> to determine preferences
1608for IPv4 or IPv6. The default is unspecified (and might change, or be the result
1609of auto probing).
1610
1611Must be set to a comma-separated list of protocols or address families,
1612current supported: C<ipv4> and C<ipv6>. Only protocols mentioned will be
1613used, and preference will be given to protocols mentioned earlier in the
1614list.
1615
1616This variable can effectively be used for denial-of-service attacks
1617against local programs (e.g. when setuid), although the impact is likely
1618small, as the program has to handle conenction and other failures anyways.
1619
1620Examples: C<PERL_ANYEVENT_PROTOCOLS=ipv4,ipv6> - prefer IPv4 over IPv6,
1621but support both and try to use both. C<PERL_ANYEVENT_PROTOCOLS=ipv4>
1622- only support IPv4, never try to resolve or contact IPv6
1623addresses. C<PERL_ANYEVENT_PROTOCOLS=ipv6,ipv4> support either IPv4 or
1624IPv6, but prefer IPv6 over IPv4.
1625
1626=item C<PERL_ANYEVENT_EDNS0>
1627
1628Used by L<AnyEvent::DNS> to decide whether to use the EDNS0 extension
1629for DNS. This extension is generally useful to reduce DNS traffic, but
1630some (broken) firewalls drop such DNS packets, which is why it is off by
1631default.
1632
1633Setting this variable to C<1> will cause L<AnyEvent::DNS> to announce
1634EDNS0 in its DNS requests.
1635
1636=item C<PERL_ANYEVENT_MAX_FORKS>
1637
1638The maximum number of child processes that C<AnyEvent::Util::fork_call>
1639will create in parallel.
1640
1641=item C<PERL_ANYEVENT_MAX_OUTSTANDING_DNS>
1642
1643The default value for the C<max_outstanding> parameter for the default DNS
1644resolver - this is the maximum number of parallel DNS requests that are
1645sent to the DNS server.
1646
1647=item C<PERL_ANYEVENT_RESOLV_CONF>
1648
1649The file to use instead of F</etc/resolv.conf> (or OS-specific
1650configuration) in the default resolver. When set to the empty string, no
1651default config will be used.
1652
1653=item C<PERL_ANYEVENT_CA_FILE>, C<PERL_ANYEVENT_CA_PATH>.
1654
1655When neither C<ca_file> nor C<ca_path> was specified during
1656L<AnyEvent::TLS> context creation, and either of these environment
1657variables exist, they will be used to specify CA certificate locations
1658instead of a system-dependent default.
1659
1660=item C<PERL_ANYEVENT_AVOID_GUARD> and C<PERL_ANYEVENT_AVOID_ASYNC_INTERRUPT>
1661
1662When these are set to C<1>, then the respective modules are not
1663loaded. Mostly good for testing AnyEvent itself.
1664
1665=back
628 1666
629=head1 SUPPLYING YOUR OWN EVENT MODEL INTERFACE 1667=head1 SUPPLYING YOUR OWN EVENT MODEL INTERFACE
630 1668
631This is an advanced topic that you do not normally need to use AnyEvent in 1669This 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 1670a 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 1705I<rxvt-unicode> also cheats a bit by not providing blocking access to
668condition variables: code blocking while waiting for a condition will 1706condition variables: code blocking while waiting for a condition will
669C<die>. This still works with most modules/usages, and blocking calls must 1707C<die>. This still works with most modules/usages, and blocking calls must
670not be done in an interactive application, so it makes sense. 1708not be done in an interactive application, so it makes sense.
671 1709
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 1710=head1 EXAMPLE PROGRAM
710 1711
711The following program uses an IO watcher to read data from STDIN, a timer 1712The 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 1713to display a message once per second, and a condition variable to quit the
713program when the user enters quit: 1714program when the user enters quit:
714 1715
715 use AnyEvent; 1716 use AnyEvent;
716 1717
721 poll => 'r', 1722 poll => 'r',
722 cb => sub { 1723 cb => sub {
723 warn "io event <$_[0]>\n"; # will always output <r> 1724 warn "io event <$_[0]>\n"; # will always output <r>
724 chomp (my $input = <STDIN>); # read a line 1725 chomp (my $input = <STDIN>); # read a line
725 warn "read: $input\n"; # output what has been read 1726 warn "read: $input\n"; # output what has been read
726 $cv->broadcast if $input =~ /^q/i; # quit program if /^q/i 1727 $cv->send if $input =~ /^q/i; # quit program if /^q/i
727 }, 1728 },
728 ); 1729 );
729 1730
730 my $time_watcher; # can only be used once 1731 my $time_watcher; # can only be used once
731 1732
736 }); 1737 });
737 } 1738 }
738 1739
739 new_timer; # create first timer 1740 new_timer; # create first timer
740 1741
741 $cv->wait; # wait until user enters /^q/i 1742 $cv->recv; # wait until user enters /^q/i
742 1743
743=head1 REAL-WORLD EXAMPLE 1744=head1 REAL-WORLD EXAMPLE
744 1745
745Consider the L<Net::FCP> module. It features (among others) the following 1746Consider the L<Net::FCP> module. It features (among others) the following
746API calls, which are to freenet what HTTP GET requests are to http: 1747API calls, which are to freenet what HTTP GET requests are to http:
796 syswrite $txn->{fh}, $txn->{request} 1797 syswrite $txn->{fh}, $txn->{request}
797 or die "connection or write error"; 1798 or die "connection or write error";
798 $txn->{w} = AnyEvent->io (fh => $txn->{fh}, poll => 'r', cb => sub { $txn->fh_ready_r }); 1799 $txn->{w} = AnyEvent->io (fh => $txn->{fh}, poll => 'r', cb => sub { $txn->fh_ready_r });
799 1800
800Again, C<fh_ready_r> waits till all data has arrived, and then stores the 1801Again, 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: 1802result and signals any possible waiters that the request has finished:
802 1803
803 sysread $txn->{fh}, $txn->{buf}, length $txn->{$buf}; 1804 sysread $txn->{fh}, $txn->{buf}, length $txn->{$buf};
804 1805
805 if (end-of-file or data complete) { 1806 if (end-of-file or data complete) {
806 $txn->{result} = $txn->{buf}; 1807 $txn->{result} = $txn->{buf};
807 $txn->{finished}->broadcast; 1808 $txn->{finished}->send;
808 $txb->{cb}->($txn) of $txn->{cb}; # also call callback 1809 $txb->{cb}->($txn) of $txn->{cb}; # also call callback
809 } 1810 }
810 1811
811The C<result> method, finally, just waits for the finished signal (if the 1812The 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 1813request was already finished, it doesn't wait, of course, and returns the
813data: 1814data:
814 1815
815 $txn->{finished}->wait; 1816 $txn->{finished}->recv;
816 return $txn->{result}; 1817 return $txn->{result};
817 1818
818The actual code goes further and collects all errors (C<die>s, exceptions) 1819The actual code goes further and collects all errors (C<die>s, exceptions)
819that occured during request processing. The C<result> method detects 1820that occurred during request processing. The C<result> method detects
820whether an exception as thrown (it is stored inside the $txn object) 1821whether an exception as thrown (it is stored inside the $txn object)
821and just throws the exception, which means connection errors and other 1822and 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 1823problems get reported tot he code that tries to use the result, not in a
823random callback. 1824random callback.
824 1825
855 1856
856 my $quit = AnyEvent->condvar; 1857 my $quit = AnyEvent->condvar;
857 1858
858 $fcp->txn_client_get ($url)->cb (sub { 1859 $fcp->txn_client_get ($url)->cb (sub {
859 ... 1860 ...
860 $quit->broadcast; 1861 $quit->send;
861 }); 1862 });
862 1863
863 $quit->wait; 1864 $quit->recv;
864 1865
865 1866
866=head1 BENCHMARK 1867=head1 BENCHMARKS
867 1868
868To give you an idea of the performance and overheads that AnyEvent adds 1869To give you an idea of the performance and overheads that AnyEvent adds
869over the event loops themselves (and to give you an impression of the 1870over the event loops themselves and to give you an impression of the speed
870speed of various event loops), here is a benchmark of various supported 1871of various event loops I prepared some benchmarks.
871event models natively and with anyevent. The benchmark creates a lot of 1872
872timers (with a zero timeout) and io watchers (watching STDOUT, a pty, to 1873=head2 BENCHMARKING ANYEVENT OVERHEAD
1874
1875Here is a benchmark of various supported event models used natively and
1876through AnyEvent. The benchmark creates a lot of timers (with a zero
1877timeout) and I/O watchers (watching STDOUT, a pty, to become writable,
873become writable, which it is), lets them fire exactly once and destroys 1878which it is), lets them fire exactly once and destroys them again.
874them again.
875 1879
876Rewriting the benchmark to use many different sockets instead of using 1880Source code for this benchmark is found as F<eg/bench> in the AnyEvent
877the same filehandle for all io watchers results in a much longer runtime 1881distribution.
878(socket creation is expensive), but qualitatively the same figures, so it
879was not used.
880 1882
881=head2 Explanation of the columns 1883=head3 Explanation of the columns
882 1884
883I<watcher> is the number of event watchers created/destroyed. Since 1885I<watcher> is the number of event watchers created/destroyed. Since
884different event models feature vastly different performances, each event 1886different event models feature vastly different performances, each event
885loop was given a number of watchers so that overall runtime is acceptable 1887loop was given a number of watchers so that overall runtime is acceptable
886and similar between tested event loop (and keep them from crashing): Glib 1888and similar between tested event loop (and keep them from crashing): Glib
896all watchers, to avoid adding memory overhead. That means closure creation 1898all watchers, to avoid adding memory overhead. That means closure creation
897and memory usage is not included in the figures. 1899and memory usage is not included in the figures.
898 1900
899I<invoke> is the time, in microseconds, used to invoke a simple 1901I<invoke> is the time, in microseconds, used to invoke a simple
900callback. The callback simply counts down a Perl variable and after it was 1902callback. The callback simply counts down a Perl variable and after it was
901invoked "watcher" times, it would C<< ->broadcast >> a condvar once to 1903invoked "watcher" times, it would C<< ->send >> a condvar once to
902signal the end of this phase. 1904signal the end of this phase.
903 1905
904I<destroy> is the time, in microseconds, that it takes to destroy a single 1906I<destroy> is the time, in microseconds, that it takes to destroy a single
905watcher. 1907watcher.
906 1908
907=head2 Results 1909=head3 Results
908 1910
909 name watchers bytes create invoke destroy comment 1911 name watchers bytes create invoke destroy comment
910 EV/EV 400000 244 0.56 0.46 0.31 EV native interface 1912 EV/EV 400000 224 0.47 0.35 0.27 EV native interface
911 EV/Any 100000 610 3.52 0.91 0.75 EV + AnyEvent watchers 1913 EV/Any 100000 224 2.88 0.34 0.27 EV + AnyEvent watchers
912 CoroEV/Any 100000 610 3.49 0.92 0.75 coroutines + Coro::Signal 1914 CoroEV/Any 100000 224 2.85 0.35 0.28 coroutines + Coro::Signal
913 Perl/Any 100000 513 4.91 0.92 1.15 pure perl implementation 1915 Perl/Any 100000 452 4.13 0.73 0.95 pure perl implementation
914 Event/Event 16000 523 28.05 21.38 0.86 Event native interface 1916 Event/Event 16000 517 32.20 31.80 0.81 Event native interface
915 Event/Any 16000 943 34.43 20.48 1.39 Event + AnyEvent watchers 1917 Event/Any 16000 590 35.85 31.55 1.06 Event + AnyEvent watchers
1918 IOAsync/Any 16000 989 38.10 32.77 11.13 via IO::Async::Loop::IO_Poll
1919 IOAsync/Any 16000 990 37.59 29.50 10.61 via IO::Async::Loop::Epoll
916 Glib/Any 16000 1357 96.99 12.55 55.51 quadratic behaviour 1920 Glib/Any 16000 1357 102.33 12.31 51.00 quadratic behaviour
917 Tk/Any 2000 1855 27.01 66.61 14.03 SEGV with >> 2000 watchers 1921 Tk/Any 2000 1860 27.20 66.31 14.00 SEGV with >> 2000 watchers
918 POE/Event 2000 6644 108.15 768.19 14.33 via POE::Loop::Event 1922 POE/Event 2000 6328 109.99 751.67 14.02 via POE::Loop::Event
919 POE/Select 2000 6343 94.69 807.65 562.69 via POE::Loop::Select 1923 POE/Select 2000 6027 94.54 809.13 579.80 via POE::Loop::Select
920 1924
921=head2 Discussion 1925=head3 Discussion
922 1926
923The benchmark does I<not> measure scalability of the event loop very 1927The benchmark does I<not> measure scalability of the event loop very
924well. For example, a select-based event loop (such as the pure perl one) 1928well. For example, a select-based event loop (such as the pure perl one)
925can never compete with an event loop that uses epoll when the number of 1929can never compete with an event loop that uses epoll when the number of
926file descriptors grows high. In this benchmark, only a single filehandle 1930file descriptors grows high. In this benchmark, all events become ready at
927is used (although some of the AnyEvent adaptors dup() its file descriptor 1931the same time, so select/poll-based implementations get an unnatural speed
928to worka round bugs). 1932boost.
1933
1934Also, note that the number of watchers usually has a nonlinear effect on
1935overall speed, that is, creating twice as many watchers doesn't take twice
1936the time - usually it takes longer. This puts event loops tested with a
1937higher number of watchers at a disadvantage.
1938
1939To put the range of results into perspective, consider that on the
1940benchmark machine, handling an event takes roughly 1600 CPU cycles with
1941EV, 3100 CPU cycles with AnyEvent's pure perl loop and almost 3000000 CPU
1942cycles with POE.
929 1943
930C<EV> is the sole leader regarding speed and memory use, which are both 1944C<EV> is the sole leader regarding speed and memory use, which are both
931maximal/minimal, respectively. Even when going through AnyEvent, there are 1945maximal/minimal, respectively. Even when going through AnyEvent, it uses
932only two event loops that use slightly less memory (the C<Event> module 1946far less memory than any other event loop and is still faster than Event
933natively and the pure perl backend), and no faster event models, not even 1947natively.
934C<Event> natively.
935 1948
936The pure perl implementation is hit in a few sweet spots (both the 1949The pure perl implementation is hit in a few sweet spots (both the
937zero timeout and the use of a single fd hit optimisations in the perl 1950constant timeout and the use of a single fd hit optimisations in the perl
938interpreter and the backend itself, and all watchers become ready at the 1951interpreter and the backend itself). Nevertheless this shows that it
939same time). Nevertheless this shows that it adds very little overhead in 1952adds very little overhead in itself. Like any select-based backend its
940itself. Like any select-based backend its performance becomes really bad 1953performance becomes really bad with lots of file descriptors (and few of
941with lots of file descriptors (and few of them active), of course, but 1954them active), of course, but this was not subject of this benchmark.
942this was not subject of this benchmark.
943 1955
944The C<Event> module has a relatively high setup and callback invocation cost, 1956The C<Event> module has a relatively high setup and callback invocation
945but overall scores on the third place. 1957cost, but overall scores in on the third place.
946 1958
1959C<IO::Async> performs admirably well, about on par with C<Event>, even
1960when using its pure perl backend.
1961
947C<Glib>'s memory usage is quite a bit bit higher, but it features a 1962C<Glib>'s memory usage is quite a bit higher, but it features a
948faster callback invocation and overall ends up in the same class as 1963faster callback invocation and overall ends up in the same class as
949C<Event>. However, Glib scales extremely badly, doubling the number of 1964C<Event>. However, Glib scales extremely badly, doubling the number of
950watchers increases the processing time by more than a factor of four, 1965watchers increases the processing time by more than a factor of four,
951making it completely unusable when using larger numbers of watchers 1966making it completely unusable when using larger numbers of watchers
952(note that only a single file descriptor was used in the benchmark, so 1967(note that only a single file descriptor was used in the benchmark, so
955The C<Tk> adaptor works relatively well. The fact that it crashes with 1970The C<Tk> adaptor works relatively well. The fact that it crashes with
956more than 2000 watchers is a big setback, however, as correctness takes 1971more than 2000 watchers is a big setback, however, as correctness takes
957precedence over speed. Nevertheless, its performance is surprising, as the 1972precedence over speed. Nevertheless, its performance is surprising, as the
958file descriptor is dup()ed for each watcher. This shows that the dup() 1973file descriptor is dup()ed for each watcher. This shows that the dup()
959employed by some adaptors is not a big performance issue (it does incur a 1974employed by some adaptors is not a big performance issue (it does incur a
960hidden memory cost inside the kernel, though, that is not reflected in the 1975hidden memory cost inside the kernel which is not reflected in the figures
961figures above). 1976above).
962 1977
963C<POE>, regardless of underlying event loop (wether using its pure perl 1978C<POE>, regardless of underlying event loop (whether using its pure perl
964select-based backend or the Event module) shows abysmal performance and 1979select-based backend or the Event module, the POE-EV backend couldn't
1980be tested because it wasn't working) shows abysmal performance and
965memory usage: Watchers use almost 30 times as much memory as EV watchers, 1981memory usage with AnyEvent: Watchers use almost 30 times as much memory
966and 10 times as much memory as both Event or EV via AnyEvent. Watcher 1982as EV watchers, and 10 times as much memory as Event (the high memory
1983requirements are caused by requiring a session for each watcher). Watcher
967invocation is almost 700 times slower than with AnyEvent's pure perl 1984invocation speed is almost 900 times slower than with AnyEvent's pure perl
1985implementation.
1986
968implementation. The design of the POE adaptor class in AnyEvent can not 1987The design of the POE adaptor class in AnyEvent can not really account
969really account for this, as session creation overhead is small compared 1988for the performance issues, though, as session creation overhead is
970to execution of the state machine, which is coded pretty optimally within 1989small compared to execution of the state machine, which is coded pretty
971L<AnyEvent::Impl::POE>. POE simply seems to be abysmally slow. 1990optimally within L<AnyEvent::Impl::POE> (and while everybody agrees that
1991using multiple sessions is not a good approach, especially regarding
1992memory usage, even the author of POE could not come up with a faster
1993design).
972 1994
973=head2 Summary 1995=head3 Summary
974 1996
1997=over 4
1998
975Using EV through AnyEvent is faster than any other event loop, but most 1999=item * Using EV through AnyEvent is faster than any other event loop
976event loops have acceptable performance with or without AnyEvent. 2000(even when used without AnyEvent), but most event loops have acceptable
2001performance with or without AnyEvent.
977 2002
978The overhead AnyEvent adds is usually much smaller than the overhead of 2003=item * The overhead AnyEvent adds is usually much smaller than the overhead of
979the actual event loop, only with extremely fast event loops such as the EV 2004the actual event loop, only with extremely fast event loops such as EV
980adds AnyEvent significant overhead. 2005adds AnyEvent significant overhead.
981 2006
982And you should simply avoid POE like the plague if you want performance or 2007=item * You should avoid POE like the plague if you want performance or
983reasonable memory usage. 2008reasonable memory usage.
984 2009
2010=back
2011
2012=head2 BENCHMARKING THE LARGE SERVER CASE
2013
2014This benchmark actually benchmarks the event loop itself. It works by
2015creating a number of "servers": each server consists of a socket pair, a
2016timeout watcher that gets reset on activity (but never fires), and an I/O
2017watcher waiting for input on one side of the socket. Each time the socket
2018watcher reads a byte it will write that byte to a random other "server".
2019
2020The effect is that there will be a lot of I/O watchers, only part of which
2021are active at any one point (so there is a constant number of active
2022fds for each loop iteration, but which fds these are is random). The
2023timeout is reset each time something is read because that reflects how
2024most timeouts work (and puts extra pressure on the event loops).
2025
2026In this benchmark, we use 10000 socket pairs (20000 sockets), of which 100
2027(1%) are active. This mirrors the activity of large servers with many
2028connections, most of which are idle at any one point in time.
2029
2030Source code for this benchmark is found as F<eg/bench2> in the AnyEvent
2031distribution.
2032
2033=head3 Explanation of the columns
2034
2035I<sockets> is the number of sockets, and twice the number of "servers" (as
2036each server has a read and write socket end).
2037
2038I<create> is the time it takes to create a socket pair (which is
2039nontrivial) and two watchers: an I/O watcher and a timeout watcher.
2040
2041I<request>, the most important value, is the time it takes to handle a
2042single "request", that is, reading the token from the pipe and forwarding
2043it to another server. This includes deleting the old timeout and creating
2044a new one that moves the timeout into the future.
2045
2046=head3 Results
2047
2048 name sockets create request
2049 EV 20000 69.01 11.16
2050 Perl 20000 73.32 35.87
2051 IOAsync 20000 157.00 98.14 epoll
2052 IOAsync 20000 159.31 616.06 poll
2053 Event 20000 212.62 257.32
2054 Glib 20000 651.16 1896.30
2055 POE 20000 349.67 12317.24 uses POE::Loop::Event
2056
2057=head3 Discussion
2058
2059This benchmark I<does> measure scalability and overall performance of the
2060particular event loop.
2061
2062EV is again fastest. Since it is using epoll on my system, the setup time
2063is relatively high, though.
2064
2065Perl surprisingly comes second. It is much faster than the C-based event
2066loops Event and Glib.
2067
2068IO::Async performs very well when using its epoll backend, and still quite
2069good compared to Glib when using its pure perl backend.
2070
2071Event suffers from high setup time as well (look at its code and you will
2072understand why). Callback invocation also has a high overhead compared to
2073the C<< $_->() for .. >>-style loop that the Perl event loop uses. Event
2074uses select or poll in basically all documented configurations.
2075
2076Glib is hit hard by its quadratic behaviour w.r.t. many watchers. It
2077clearly fails to perform with many filehandles or in busy servers.
2078
2079POE is still completely out of the picture, taking over 1000 times as long
2080as EV, and over 100 times as long as the Perl implementation, even though
2081it uses a C-based event loop in this case.
2082
2083=head3 Summary
2084
2085=over 4
2086
2087=item * The pure perl implementation performs extremely well.
2088
2089=item * Avoid Glib or POE in large projects where performance matters.
2090
2091=back
2092
2093=head2 BENCHMARKING SMALL SERVERS
2094
2095While event loops should scale (and select-based ones do not...) even to
2096large servers, most programs we (or I :) actually write have only a few
2097I/O watchers.
2098
2099In this benchmark, I use the same benchmark program as in the large server
2100case, but it uses only eight "servers", of which three are active at any
2101one time. This should reflect performance for a small server relatively
2102well.
2103
2104The columns are identical to the previous table.
2105
2106=head3 Results
2107
2108 name sockets create request
2109 EV 16 20.00 6.54
2110 Perl 16 25.75 12.62
2111 Event 16 81.27 35.86
2112 Glib 16 32.63 15.48
2113 POE 16 261.87 276.28 uses POE::Loop::Event
2114
2115=head3 Discussion
2116
2117The benchmark tries to test the performance of a typical small
2118server. While knowing how various event loops perform is interesting, keep
2119in mind that their overhead in this case is usually not as important, due
2120to the small absolute number of watchers (that is, you need efficiency and
2121speed most when you have lots of watchers, not when you only have a few of
2122them).
2123
2124EV is again fastest.
2125
2126Perl again comes second. It is noticeably faster than the C-based event
2127loops Event and Glib, although the difference is too small to really
2128matter.
2129
2130POE also performs much better in this case, but is is still far behind the
2131others.
2132
2133=head3 Summary
2134
2135=over 4
2136
2137=item * C-based event loops perform very well with small number of
2138watchers, as the management overhead dominates.
2139
2140=back
2141
2142=head2 THE IO::Lambda BENCHMARK
2143
2144Recently I was told about the benchmark in the IO::Lambda manpage, which
2145could be misinterpreted to make AnyEvent look bad. In fact, the benchmark
2146simply compares IO::Lambda with POE, and IO::Lambda looks better (which
2147shouldn't come as a surprise to anybody). As such, the benchmark is
2148fine, and mostly shows that the AnyEvent backend from IO::Lambda isn't
2149very optimal. But how would AnyEvent compare when used without the extra
2150baggage? To explore this, I wrote the equivalent benchmark for AnyEvent.
2151
2152The benchmark itself creates an echo-server, and then, for 500 times,
2153connects to the echo server, sends a line, waits for the reply, and then
2154creates the next connection. This is a rather bad benchmark, as it doesn't
2155test the efficiency of the framework or much non-blocking I/O, but it is a
2156benchmark nevertheless.
2157
2158 name runtime
2159 Lambda/select 0.330 sec
2160 + optimized 0.122 sec
2161 Lambda/AnyEvent 0.327 sec
2162 + optimized 0.138 sec
2163 Raw sockets/select 0.077 sec
2164 POE/select, components 0.662 sec
2165 POE/select, raw sockets 0.226 sec
2166 POE/select, optimized 0.404 sec
2167
2168 AnyEvent/select/nb 0.085 sec
2169 AnyEvent/EV/nb 0.068 sec
2170 +state machine 0.134 sec
2171
2172The benchmark is also a bit unfair (my fault): the IO::Lambda/POE
2173benchmarks actually make blocking connects and use 100% blocking I/O,
2174defeating the purpose of an event-based solution. All of the newly
2175written AnyEvent benchmarks use 100% non-blocking connects (using
2176AnyEvent::Socket::tcp_connect and the asynchronous pure perl DNS
2177resolver), so AnyEvent is at a disadvantage here, as non-blocking connects
2178generally require a lot more bookkeeping and event handling than blocking
2179connects (which involve a single syscall only).
2180
2181The last AnyEvent benchmark additionally uses L<AnyEvent::Handle>, which
2182offers similar expressive power as POE and IO::Lambda, using conventional
2183Perl syntax. This means that both the echo server and the client are 100%
2184non-blocking, further placing it at a disadvantage.
2185
2186As you can see, the AnyEvent + EV combination even beats the
2187hand-optimised "raw sockets benchmark", while AnyEvent + its pure perl
2188backend easily beats IO::Lambda and POE.
2189
2190And even the 100% non-blocking version written using the high-level (and
2191slow :) L<AnyEvent::Handle> abstraction beats both POE and IO::Lambda by a
2192large margin, even though it does all of DNS, tcp-connect and socket I/O
2193in a non-blocking way.
2194
2195The two AnyEvent benchmarks programs can be found as F<eg/ae0.pl> and
2196F<eg/ae2.pl> in the AnyEvent distribution, the remaining benchmarks are
2197part of the IO::lambda distribution and were used without any changes.
2198
2199
2200=head1 SIGNALS
2201
2202AnyEvent currently installs handlers for these signals:
2203
2204=over 4
2205
2206=item SIGCHLD
2207
2208A handler for C<SIGCHLD> is installed by AnyEvent's child watcher
2209emulation for event loops that do not support them natively. Also, some
2210event loops install a similar handler.
2211
2212Additionally, when AnyEvent is loaded and SIGCHLD is set to IGNORE, then
2213AnyEvent will reset it to default, to avoid losing child exit statuses.
2214
2215=item SIGPIPE
2216
2217A no-op handler is installed for C<SIGPIPE> when C<$SIG{PIPE}> is C<undef>
2218when AnyEvent gets loaded.
2219
2220The rationale for this is that AnyEvent users usually do not really depend
2221on SIGPIPE delivery (which is purely an optimisation for shell use, or
2222badly-written programs), but C<SIGPIPE> can cause spurious and rare
2223program exits as a lot of people do not expect C<SIGPIPE> when writing to
2224some random socket.
2225
2226The rationale for installing a no-op handler as opposed to ignoring it is
2227that this way, the handler will be restored to defaults on exec.
2228
2229Feel free to install your own handler, or reset it to defaults.
2230
2231=back
2232
2233=cut
2234
2235undef $SIG{CHLD}
2236 if $SIG{CHLD} eq 'IGNORE';
2237
2238$SIG{PIPE} = sub { }
2239 unless defined $SIG{PIPE};
2240
2241=head1 RECOMMENDED/OPTIONAL MODULES
2242
2243One of AnyEvent's main goals is to be 100% Pure-Perl(tm): only perl (and
2244it's built-in modules) are required to use it.
2245
2246That does not mean that AnyEvent won't take advantage of some additional
2247modules if they are installed.
2248
2249This section epxlains which additional modules will be used, and how they
2250affect AnyEvent's operetion.
2251
2252=over 4
2253
2254=item L<Async::Interrupt>
2255
2256This slightly arcane module is used to implement fast signal handling: To
2257my knowledge, there is no way to do completely race-free and quick
2258signal handling in pure perl. To ensure that signals still get
2259delivered, AnyEvent will start an interval timer to wake up perl (and
2260catch the signals) with soemd elay (default is 10 seconds, look for
2261C<$AnyEvent::MAX_SIGNAL_LATENCY>).
2262
2263If this module is available, then it will be used to implement signal
2264catching, which means that signals will not be delayed, and the event loop
2265will not be interrupted regularly, which is more efficient (And good for
2266battery life on laptops).
2267
2268This affects not just the pure-perl event loop, but also other event loops
2269that have no signal handling on their own (e.g. Glib, Tk, Qt).
2270
2271=item L<EV>
2272
2273This module isn't really "optional", as it is simply one of the backend
2274event loops that AnyEvent can use. However, it is simply the best event
2275loop available in terms of features, speed and stability: It supports
2276the AnyEvent API optimally, implements all the watcher types in XS, does
2277automatic timer adjustments even when no monotonic clock is available,
2278can take avdantage of advanced kernel interfaces such as C<epoll> and
2279C<kqueue>, and is the fastest backend I<by far>. You can even embed
2280L<Glib>/L<Gtk2> in it (or vice versa, see L<EV::Glib> and L<Glib::EV>).
2281
2282=item L<Guard>
2283
2284The guard module, when used, will be used to implement
2285C<AnyEvent::Util::guard>. This speeds up guards considerably (and uses a
2286lot less memory), but otherwise doesn't affect guard operation much. It is
2287purely used for performance.
2288
2289=item L<JSON> and L<JSON::XS>
2290
2291This module is required when you want to read or write JSON data via
2292L<AnyEvent::Handle>. It is also written in pure-perl, but can take
2293advantage of the ulta-high-speed L<JSON::XS> module when it is installed.
2294
2295In fact, L<AnyEvent::Handle> will use L<JSON::XS> by default if it is
2296installed.
2297
2298=item L<Net::SSLeay>
2299
2300Implementing TLS/SSL in Perl is certainly interesting, but not very
2301worthwhile: If this module is installed, then L<AnyEvent::Handle> (with
2302the help of L<AnyEvent::TLS>), gains the ability to do TLS/SSL.
2303
2304=item L<Time::HiRes>
2305
2306This module is part of perl since release 5.008. It will be used when the
2307chosen event library does not come with a timing source on it's own. The
2308pure-perl event loop (L<AnyEvent::Impl::Perl>) will additionally use it to
2309try to use a monotonic clock for timing stability.
2310
2311=back
2312
985 2313
986=head1 FORK 2314=head1 FORK
987 2315
988Most event libraries are not fork-safe. The ones who are usually are 2316Most event libraries are not fork-safe. The ones who are usually are
989because they are so inefficient. Only L<EV> is fully fork-aware. 2317because they rely on inefficient but fork-safe C<select> or C<poll>
2318calls. Only L<EV> is fully fork-aware.
990 2319
991If you have to fork, you must either do so I<before> creating your first 2320If you have to fork, you must either do so I<before> creating your first
992watcher OR you must not use AnyEvent at all in the child. 2321watcher OR you must not use AnyEvent at all in the child OR you must do
2322something completely out of the scope of AnyEvent.
993 2323
994 2324
995=head1 SECURITY CONSIDERATIONS 2325=head1 SECURITY CONSIDERATIONS
996 2326
997AnyEvent can be forced to load any event model via 2327AnyEvent can be forced to load any event model via
1002specified in the variable. 2332specified in the variable.
1003 2333
1004You can make AnyEvent completely ignore this variable by deleting it 2334You can make AnyEvent completely ignore this variable by deleting it
1005before the first watcher gets created, e.g. with a C<BEGIN> block: 2335before the first watcher gets created, e.g. with a C<BEGIN> block:
1006 2336
1007 BEGIN { delete $ENV{PERL_ANYEVENT_MODEL} } 2337 BEGIN { delete $ENV{PERL_ANYEVENT_MODEL} }
1008 2338
1009 use AnyEvent; 2339 use AnyEvent;
2340
2341Similar considerations apply to $ENV{PERL_ANYEVENT_VERBOSE}, as that can
2342be used to probe what backend is used and gain other information (which is
2343probably even less useful to an attacker than PERL_ANYEVENT_MODEL), and
2344$ENV{PERL_ANYEVENT_STRICT}.
2345
2346Note that AnyEvent will remove I<all> environment variables starting with
2347C<PERL_ANYEVENT_> from C<%ENV> when it is loaded while taint mode is
2348enabled.
2349
2350
2351=head1 BUGS
2352
2353Perl 5.8 has numerous memleaks that sometimes hit this module and are hard
2354to work around. If you suffer from memleaks, first upgrade to Perl 5.10
2355and check wether the leaks still show up. (Perl 5.10.0 has other annoying
2356memleaks, such as leaking on C<map> and C<grep> but it is usually not as
2357pronounced).
1010 2358
1011 2359
1012=head1 SEE ALSO 2360=head1 SEE ALSO
1013 2361
1014Event modules: L<Coro::EV>, L<EV>, L<EV::Glib>, L<Glib::EV>, 2362Utility functions: L<AnyEvent::Util>.
1015L<Coro::Event>, L<Event>, L<Glib::Event>, L<Glib>, L<Coro>, L<Tk>, 2363
2364Event modules: L<EV>, L<EV::Glib>, L<Glib::EV>, L<Event>, L<Glib::Event>,
1016L<Event::Lib>, L<Qt>, L<POE>. 2365L<Glib>, L<Tk>, L<Event::Lib>, L<Qt>, L<POE>.
1017 2366
1018Implementations: L<AnyEvent::Impl::CoroEV>, L<AnyEvent::Impl::EV>, 2367Implementations: L<AnyEvent::Impl::EV>, L<AnyEvent::Impl::Event>,
1019L<AnyEvent::Impl::CoroEvent>, L<AnyEvent::Impl::Event>, L<AnyEvent::Impl::Glib>, 2368L<AnyEvent::Impl::Glib>, L<AnyEvent::Impl::Tk>, L<AnyEvent::Impl::Perl>,
1020L<AnyEvent::Impl::Tk>, L<AnyEvent::Impl::Perl>, L<AnyEvent::Impl::EventLib>, 2369L<AnyEvent::Impl::EventLib>, L<AnyEvent::Impl::Qt>,
1021L<AnyEvent::Impl::Qt>, L<AnyEvent::Impl::POE>. 2370L<AnyEvent::Impl::POE>, L<AnyEvent::Impl::IOAsync>.
1022 2371
2372Non-blocking file handles, sockets, TCP clients and
2373servers: L<AnyEvent::Handle>, L<AnyEvent::Socket>, L<AnyEvent::TLS>.
2374
2375Asynchronous DNS: L<AnyEvent::DNS>.
2376
2377Coroutine support: L<Coro>, L<Coro::AnyEvent>, L<Coro::EV>,
2378L<Coro::Event>,
2379
1023Nontrivial usage examples: L<Net::FCP>, L<Net::XMPP2>. 2380Nontrivial usage examples: L<AnyEvent::GPSD>, L<AnyEvent::XMPP>,
2381L<AnyEvent::HTTP>.
1024 2382
1025 2383
1026=head1 AUTHOR 2384=head1 AUTHOR
1027 2385
1028 Marc Lehmann <schmorp@schmorp.de> 2386 Marc Lehmann <schmorp@schmorp.de>
1029 http://home.schmorp.de/ 2387 http://home.schmorp.de/
1030 2388
1031=cut 2389=cut
1032 2390
10331 23911
1034 2392

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines