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

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines