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

Comparing AnyEvent/README (file contents):
Revision 1.61 by root, Wed Apr 28 14:15:55 2010 UTC vs.
Revision 1.73 by root, Fri Sep 5 22:24:12 2014 UTC

1NAME 1NAME
2 AnyEvent - the DBI of event loop programming 2 AnyEvent - the DBI of event loop programming
3 3
4 EV, Event, Glib, Tk, Perl, Event::Lib, Irssi, rxvt-unicode, IO::Async, 4 EV, Event, Glib, Tk, UV, Perl, Event::Lib, Irssi, rxvt-unicode,
5 Qt and POE are various supported event loops/environments. 5 IO::Async, Qt, FLTK and POE are various supported event
6 loops/environments.
6 7
7SYNOPSIS 8SYNOPSIS
8 use AnyEvent; 9 use AnyEvent;
9 10
10 # if you prefer function calls, look at the L<AE> manpage for 11 # if you prefer function calls, look at the AE manpage for
11 # an alternative API. 12 # an alternative API.
12 13
13 # file handle or descriptor readable 14 # file handle or descriptor readable
14 my $w = AnyEvent->io (fh => $fh, poll => "r", cb => sub { ... }); 15 my $w = AnyEvent->io (fh => $fh, poll => "r", cb => sub { ... });
15 16
16 # one-shot or repeating timers 17 # one-shot or repeating timers
17 my $w = AnyEvent->timer (after => $seconds, cb => sub { ... }); 18 my $w = AnyEvent->timer (after => $seconds, cb => sub { ... });
18 my $w = AnyEvent->timer (after => $seconds, interval => $seconds, cb => ... 19 my $w = AnyEvent->timer (after => $seconds, interval => $seconds, cb => ...);
19 20
20 print AnyEvent->now; # prints current event loop time 21 print AnyEvent->now; # prints current event loop time
21 print AnyEvent->time; # think Time::HiRes::time or simply CORE::time. 22 print AnyEvent->time; # think Time::HiRes::time or simply CORE::time.
22 23
23 # POSIX signal 24 # POSIX signal
42 This manpage is mainly a reference manual. If you are interested in a 43 This manpage is mainly a reference manual. If you are interested in a
43 tutorial or some gentle introduction, have a look at the AnyEvent::Intro 44 tutorial or some gentle introduction, have a look at the AnyEvent::Intro
44 manpage. 45 manpage.
45 46
46SUPPORT 47SUPPORT
48 An FAQ document is available as AnyEvent::FAQ.
49
47 There is a mailinglist for discussing all things AnyEvent, and an IRC 50 There also is a mailinglist for discussing all things AnyEvent, and an
48 channel, too. 51 IRC channel, too.
49 52
50 See the AnyEvent project page at the Schmorpforge Ta-Sa Software 53 See the AnyEvent project page at the Schmorpforge Ta-Sa Software
51 Repository, at <http://anyevent.schmorp.de>, for more info. 54 Repository, at <http://anyevent.schmorp.de>, for more info.
52 55
53WHY YOU SHOULD USE THIS MODULE (OR NOT) 56WHY YOU SHOULD USE THIS MODULE (OR NOT)
71 module users into the same thing by forcing them to use the same event 74 module users into the same thing by forcing them to use the same event
72 model you use. 75 model you use.
73 76
74 For modules like POE or IO::Async (which is a total misnomer as it is 77 For modules like POE or IO::Async (which is a total misnomer as it is
75 actually doing all I/O *synchronously*...), using them in your module is 78 actually doing all I/O *synchronously*...), using them in your module is
76 like joining a cult: After you joined, you are dependent on them and you 79 like joining a cult: After you join, you are dependent on them and you
77 cannot use anything else, as they are simply incompatible to everything 80 cannot use anything else, as they are simply incompatible to everything
78 that isn't them. What's worse, all the potential users of your module 81 that isn't them. What's worse, all the potential users of your module
79 are *also* forced to use the same event loop you use. 82 are *also* forced to use the same event loop you use.
80 83
81 AnyEvent is different: AnyEvent + POE works fine. AnyEvent + Glib works 84 AnyEvent is different: AnyEvent + POE works fine. AnyEvent + Glib works
82 fine. AnyEvent + Tk works fine etc. etc. but none of these work together 85 fine. AnyEvent + Tk works fine etc. etc. but none of these work together
83 with the rest: POE + IO::Async? No go. Tk + Event? No go. Again: if your 86 with the rest: POE + EV? No go. Tk + Event? No go. Again: if your module
84 module uses one of those, every user of your module has to use it, too. 87 uses one of those, every user of your module has to use it, too. But if
85 But if your module uses AnyEvent, it works transparently with all event 88 your module uses AnyEvent, it works transparently with all event models
86 models it supports (including stuff like IO::Async, as long as those use 89 it supports (including stuff like IO::Async, as long as those use one of
87 one of the supported event loops. It is trivial to add new event loops 90 the supported event loops. It is easy to add new event loops to
88 to AnyEvent, too, so it is future-proof). 91 AnyEvent, too, so it is future-proof).
89 92
90 In addition to being free of having to use *the one and only true event 93 In addition to being free of having to use *the one and only true event
91 model*, AnyEvent also is free of bloat and policy: with POE or similar 94 model*, AnyEvent also is free of bloat and policy: with POE or similar
92 modules, you get an enormous amount of code and strict rules you have to 95 modules, you get an enormous amount of code and strict rules you have to
93 follow. AnyEvent, on the other hand, is lean and up to the point, by 96 follow. AnyEvent, on the other hand, is lean and to the point, by only
94 only offering the functionality that is necessary, in as thin as a 97 offering the functionality that is necessary, in as thin as a wrapper as
95 wrapper as technically possible. 98 technically possible.
96 99
97 Of course, AnyEvent comes with a big (and fully optional!) toolbox of 100 Of course, AnyEvent comes with a big (and fully optional!) toolbox of
98 useful functionality, such as an asynchronous DNS resolver, 100% 101 useful functionality, such as an asynchronous DNS resolver, 100%
99 non-blocking connects (even with TLS/SSL, IPv6 and on broken platforms 102 non-blocking connects (even with TLS/SSL, IPv6 and on broken platforms
100 such as Windows) and lots of real-world knowledge and workarounds for 103 such as Windows) and lots of real-world knowledge and workarounds for
103 Now, if you *do want* lots of policy (this can arguably be somewhat 106 Now, if you *do want* lots of policy (this can arguably be somewhat
104 useful) and you want to force your users to use the one and only event 107 useful) and you want to force your users to use the one and only event
105 model, you should *not* use this module. 108 model, you should *not* use this module.
106 109
107DESCRIPTION 110DESCRIPTION
108 AnyEvent provides an identical interface to multiple event loops. This 111 AnyEvent provides a uniform interface to various event loops. This
109 allows module authors to utilise an event loop without forcing module 112 allows module authors to use event loop functionality without forcing
110 users to use the same event loop (as only a single event loop can 113 module users to use a specific event loop implementation (since more
111 coexist peacefully at any one time). 114 than one event loop cannot coexist peacefully).
112 115
113 The interface itself is vaguely similar, but not identical to the Event 116 The interface itself is vaguely similar, but not identical to the Event
114 module. 117 module.
115 118
116 During the first call of any watcher-creation method, the module tries 119 During the first call of any watcher-creation method, the module tries
117 to detect the currently loaded event loop by probing whether one of the 120 to detect the currently loaded event loop by probing whether one of the
118 following modules is already loaded: EV, Event, Glib, 121 following modules is already loaded: EV, AnyEvent::Loop, Event, Glib,
119 AnyEvent::Impl::Perl, Tk, Event::Lib, Qt, POE. The first one found is 122 Tk, Event::Lib, Qt, POE. The first one found is used. If none are
120 used. If none are found, the module tries to load these modules 123 detected, the module tries to load the first four modules in the order
121 (excluding Tk, Event::Lib, Qt and POE as the pure perl adaptor should 124 given; but note that if EV is not available, the pure-perl
122 always succeed) in the order given. The first one that can be 125 AnyEvent::Loop should always work, so the other two are not normally
123 successfully loaded will be used. If, after this, still none could be 126 tried.
124 found, AnyEvent will fall back to a pure-perl event loop, which is not
125 very efficient, but should work everywhere.
126 127
127 Because AnyEvent first checks for modules that are already loaded, 128 Because AnyEvent first checks for modules that are already loaded,
128 loading an event model explicitly before first using AnyEvent will 129 loading an event model explicitly before first using AnyEvent will
129 likely make that model the default. For example: 130 likely make that model the default. For example:
130 131
132 use AnyEvent; 133 use AnyEvent;
133 134
134 # .. AnyEvent will likely default to Tk 135 # .. AnyEvent will likely default to Tk
135 136
136 The *likely* means that, if any module loads another event model and 137 The *likely* means that, if any module loads another event model and
137 starts using it, all bets are off. Maybe you should tell their authors 138 starts using it, all bets are off - this case should be very rare
138 to use AnyEvent so their modules work together with others seamlessly... 139 though, as very few modules hardcode event loops without announcing this
140 very loudly.
139 141
140 The pure-perl implementation of AnyEvent is called 142 The pure-perl implementation of AnyEvent is called "AnyEvent::Loop".
141 "AnyEvent::Impl::Perl". Like other event modules you can load it 143 Like other event modules you can load it explicitly and enjoy the high
142 explicitly and enjoy the high availability of that event loop :) 144 availability of that event loop :)
143 145
144WATCHERS 146WATCHERS
145 AnyEvent has the central concept of a *watcher*, which is an object that 147 AnyEvent has the central concept of a *watcher*, which is an object that
146 stores relevant data for each kind of event you are waiting for, such as 148 stores relevant data for each kind of event you are waiting for, such as
147 the callback to call, the file handle to watch, etc. 149 the callback to call, the file handle to watch, etc.
151 callback when the event occurs (of course, only when the event model is 153 callback when the event occurs (of course, only when the event model is
152 in control). 154 in control).
153 155
154 Note that callbacks must not permanently change global variables 156 Note that callbacks must not permanently change global variables
155 potentially in use by the event loop (such as $_ or $[) and that 157 potentially in use by the event loop (such as $_ or $[) and that
156 callbacks must not "die". The former is good programming practise in 158 callbacks must not "die". The former is good programming practice in
157 Perl and the latter stems from the fact that exception handling differs 159 Perl and the latter stems from the fact that exception handling differs
158 widely between event loops. 160 widely between event loops.
159 161
160 To disable the watcher you have to destroy it (e.g. by setting the 162 To disable a watcher you have to destroy it (e.g. by setting the
161 variable you store it in to "undef" or otherwise deleting all references 163 variable you store it in to "undef" or otherwise deleting all references
162 to it). 164 to it).
163 165
164 All watchers are created by calling a method on the "AnyEvent" class. 166 All watchers are created by calling a method on the "AnyEvent" class.
165 167
166 Many watchers either are used with "recursion" (repeating timers for 168 Many watchers either are used with "recursion" (repeating timers for
167 example), or need to refer to their watcher object in other ways. 169 example), or need to refer to their watcher object in other ways.
168 170
169 An any way to achieve that is this pattern: 171 One way to achieve that is this pattern:
170 172
171 my $w; $w = AnyEvent->type (arg => value ..., cb => sub { 173 my $w; $w = AnyEvent->type (arg => value ..., cb => sub {
172 # you can use $w here, for example to undef it 174 # you can use $w here, for example to undef it
173 undef $w; 175 undef $w;
174 }); 176 });
205 207
206 The I/O watcher might use the underlying file descriptor or a copy of 208 The I/O watcher might use the underlying file descriptor or a copy of
207 it. You must not close a file handle as long as any watcher is active on 209 it. You must not close a file handle as long as any watcher is active on
208 the underlying file descriptor. 210 the underlying file descriptor.
209 211
210 Some event loops issue spurious readyness notifications, so you should 212 Some event loops issue spurious readiness notifications, so you should
211 always use non-blocking calls when reading/writing from/to your file 213 always use non-blocking calls when reading/writing from/to your file
212 handles. 214 handles.
213 215
214 Example: wait for readability of STDIN, then read a line and disable the 216 Example: wait for readability of STDIN, then read a line and disable the
215 watcher. 217 watcher.
238 240
239 Although the callback might get passed parameters, their value and 241 Although the callback might get passed parameters, their value and
240 presence is undefined and you cannot rely on them. Portable AnyEvent 242 presence is undefined and you cannot rely on them. Portable AnyEvent
241 callbacks cannot use arguments passed to time watcher callbacks. 243 callbacks cannot use arguments passed to time watcher callbacks.
242 244
243 The callback will normally be invoked once only. If you specify another 245 The callback will normally be invoked only once. If you specify another
244 parameter, "interval", as a strictly positive number (> 0), then the 246 parameter, "interval", as a strictly positive number (> 0), then the
245 callback will be invoked regularly at that interval (in fractional 247 callback will be invoked regularly at that interval (in fractional
246 seconds) after the first invocation. If "interval" is specified with a 248 seconds) after the first invocation. If "interval" is specified with a
247 false value, then it is treated as if it were missing. 249 false value, then it is treated as if it were not specified at all.
248 250
249 The callback will be rescheduled before invoking the callback, but no 251 The callback will be rescheduled before invoking the callback, but no
250 attempt is done to avoid timer drift in most backends, so the interval 252 attempt is made to avoid timer drift in most backends, so the interval
251 is only approximate. 253 is only approximate.
252 254
253 Example: fire an event after 7.7 seconds. 255 Example: fire an event after 7.7 seconds.
254 256
255 my $w = AnyEvent->timer (after => 7.7, cb => sub { 257 my $w = AnyEvent->timer (after => 7.7, cb => sub {
261 263
262 Example 2: fire an event after 0.5 seconds, then roughly every second. 264 Example 2: fire an event after 0.5 seconds, then roughly every second.
263 265
264 my $w = AnyEvent->timer (after => 0.5, interval => 1, cb => sub { 266 my $w = AnyEvent->timer (after => 0.5, interval => 1, cb => sub {
265 warn "timeout\n"; 267 warn "timeout\n";
266 }; 268 });
267 269
268 TIMING ISSUES 270 TIMING ISSUES
269 There are two ways to handle timers: based on real time (relative, "fire 271 There are two ways to handle timers: based on real time (relative, "fire
270 in 10 seconds") and based on wallclock time (absolute, "fire at 12 272 in 10 seconds") and based on wallclock time (absolute, "fire at 12
271 o'clock"). 273 o'clock").
272 274
273 While most event loops expect timers to specified in a relative way, 275 While most event loops expect timers to specified in a relative way,
274 they use absolute time internally. This makes a difference when your 276 they use absolute time internally. This makes a difference when your
275 clock "jumps", for example, when ntp decides to set your clock backwards 277 clock "jumps", for example, when ntp decides to set your clock backwards
276 from the wrong date of 2014-01-01 to 2008-01-01, a watcher that is 278 from the wrong date of 2014-01-01 to 2008-01-01, a watcher that is
277 supposed to fire "after" a second might actually take six years to 279 supposed to fire "after a second" might actually take six years to
278 finally fire. 280 finally fire.
279 281
280 AnyEvent cannot compensate for this. The only event loop that is 282 AnyEvent cannot compensate for this. The only event loop that is
281 conscious about these issues is EV, which offers both relative 283 conscious of these issues is EV, which offers both relative (ev_timer,
282 (ev_timer, based on true relative time) and absolute (ev_periodic, based 284 based on true relative time) and absolute (ev_periodic, based on
283 on wallclock time) timers. 285 wallclock time) timers.
284 286
285 AnyEvent always prefers relative timers, if available, matching the 287 AnyEvent always prefers relative timers, if available, matching the
286 AnyEvent API. 288 AnyEvent API.
287 289
288 AnyEvent has two additional methods that return the "current time": 290 AnyEvent has two additional methods that return the "current time":
307 *In almost all cases (in all cases if you don't care), this is the 309 *In almost all cases (in all cases if you don't care), this is the
308 function to call when you want to know the current time.* 310 function to call when you want to know the current time.*
309 311
310 This function is also often faster then "AnyEvent->time", and thus 312 This function is also often faster then "AnyEvent->time", and thus
311 the preferred method if you want some timestamp (for example, 313 the preferred method if you want some timestamp (for example,
312 AnyEvent::Handle uses this to update it's activity timeouts). 314 AnyEvent::Handle uses this to update its activity timeouts).
313 315
314 The rest of this section is only of relevance if you try to be very 316 The rest of this section is only of relevance if you try to be very
315 exact with your timing, you can skip it without bad conscience. 317 exact with your timing; you can skip it without a bad conscience.
316 318
317 For a practical example of when these times differ, consider 319 For a practical example of when these times differ, consider
318 Event::Lib and EV and the following set-up: 320 Event::Lib and EV and the following set-up:
319 321
320 The event loop is running and has just invoked one of your callback 322 The event loop is running and has just invoked one of your callbacks
321 at time=500 (assume no other callbacks delay processing). In your 323 at time=500 (assume no other callbacks delay processing). In your
322 callback, you wait a second by executing "sleep 1" (blocking the 324 callback, you wait a second by executing "sleep 1" (blocking the
323 process for a second) and then (at time=501) you create a relative 325 process for a second) and then (at time=501) you create a relative
324 timer that fires after three seconds. 326 timer that fires after three seconds.
325 327
346 can get whatever behaviour you want with any event loop, by taking 348 can get whatever behaviour you want with any event loop, by taking
347 the difference between "AnyEvent->time" and "AnyEvent->now" into 349 the difference between "AnyEvent->time" and "AnyEvent->now" into
348 account. 350 account.
349 351
350 AnyEvent->now_update 352 AnyEvent->now_update
351 Some event loops (such as EV or AnyEvent::Impl::Perl) cache the 353 Some event loops (such as EV or AnyEvent::Loop) cache the current
352 current time for each loop iteration (see the discussion of 354 time for each loop iteration (see the discussion of AnyEvent->now,
353 AnyEvent->now, above). 355 above).
354 356
355 When a callback runs for a long time (or when the process sleeps), 357 When a callback runs for a long time (or when the process sleeps),
356 then this "current" time will differ substantially from the real 358 then this "current" time will differ substantially from the real
357 time, which might affect timers and time-outs. 359 time, which might affect timers and time-outs.
358 360
402 will not restart syscalls (that includes Async::Interrupt and AnyEvent's 404 will not restart syscalls (that includes Async::Interrupt and AnyEvent's
403 pure perl implementation). 405 pure perl implementation).
404 406
405 Safe/Unsafe Signals 407 Safe/Unsafe Signals
406 Perl signals can be either "safe" (synchronous to opcode handling) or 408 Perl signals can be either "safe" (synchronous to opcode handling) or
407 "unsafe" (asynchronous) - the former might get delayed indefinitely, the 409 "unsafe" (asynchronous) - the former might delay signal delivery
408 latter might corrupt your memory. 410 indefinitely, the latter might corrupt your memory.
409 411
410 AnyEvent signal handlers are, in addition, synchronous to the event 412 AnyEvent signal handlers are, in addition, synchronous to the event
411 loop, i.e. they will not interrupt your running perl program but will 413 loop, i.e. they will not interrupt your running perl program but will
412 only be called as part of the normal event handling (just like timer, 414 only be called as part of the normal event handling (just like timer,
413 I/O etc. callbacks, too). 415 I/O etc. callbacks, too).
414 416
415 Signal Races, Delays and Workarounds 417 Signal Races, Delays and Workarounds
416 Many event loops (e.g. Glib, Tk, Qt, IO::Async) do not support attaching 418 Many event loops (e.g. Glib, Tk, Qt, IO::Async) do not support attaching
417 callbacks to signals in a generic way, which is a pity, as you cannot do 419 callbacks to signals in a generic way, which is a pity, as you cannot do
418 race-free signal handling in perl, requiring C libraries for this. 420 race-free signal handling in perl, requiring C libraries for this.
419 AnyEvent will try to do it's best, which means in some cases, signals 421 AnyEvent will try to do its best, which means in some cases, signals
420 will be delayed. The maximum time a signal might be delayed is specified 422 will be delayed. The maximum time a signal might be delayed is 10
421 in $AnyEvent::MAX_SIGNAL_LATENCY (default: 10 seconds). This variable 423 seconds by default, but can be overriden via
422 can be changed only before the first signal watcher is created, and 424 $ENV{PERL_ANYEVENT_MAX_SIGNAL_LATENCY} or $AnyEvent::MAX_SIGNAL_LATENCY
423 should be left alone otherwise. This variable determines how often 425 - see the "ENVIRONMENT VARIABLES" section for details.
424 AnyEvent polls for signals (in case a wake-up was missed). Higher values
425 will cause fewer spurious wake-ups, which is better for power and CPU
426 saving.
427 426
428 All these problems can be avoided by installing the optional 427 All these problems can be avoided by installing the optional
429 Async::Interrupt module, which works with most event loops. It will not 428 Async::Interrupt module, which works with most event loops. It will not
430 work with inherently broken event loops such as Event or Event::Lib (and 429 work with inherently broken event loops such as Event or Event::Lib (and
431 not with POE currently, as POE does it's own workaround with one-second
432 latency). For those, you just have to suffer the delays. 430 not with POE currently). For those, you just have to suffer the delays.
433 431
434 CHILD PROCESS WATCHERS 432 CHILD PROCESS WATCHERS
435 $w = AnyEvent->child (pid => <process id>, cb => <callback>); 433 $w = AnyEvent->child (pid => <process id>, cb => <callback>);
436 434
437 You can also watch on a child process exit and catch its exit status. 435 You can also watch for a child process exit and catch its exit status.
438 436
439 The child process is specified by the "pid" argument (one some backends, 437 The child process is specified by the "pid" argument (on some backends,
440 using 0 watches for any child process exit, on others this will croak). 438 using 0 watches for any child process exit, on others this will croak).
441 The watcher will be triggered only when the child process has finished 439 The watcher will be triggered only when the child process has finished
442 and an exit status is available, not on any trace events 440 and an exit status is available, not on any trace events
443 (stopped/continued). 441 (stopped/continued).
444 442
465 This means you cannot create a child watcher as the very first thing in 463 This means you cannot create a child watcher as the very first thing in
466 an AnyEvent program, you *have* to create at least one watcher before 464 an AnyEvent program, you *have* to create at least one watcher before
467 you "fork" the child (alternatively, you can call "AnyEvent::detect"). 465 you "fork" the child (alternatively, you can call "AnyEvent::detect").
468 466
469 As most event loops do not support waiting for child events, they will 467 As most event loops do not support waiting for child events, they will
470 be emulated by AnyEvent in most cases, in which the latency and race 468 be emulated by AnyEvent in most cases, in which case the latency and
471 problems mentioned in the description of signal watchers apply. 469 race problems mentioned in the description of signal watchers apply.
472 470
473 Example: fork a process and wait for it 471 Example: fork a process and wait for it
474 472
475 my $done = AnyEvent->condvar; 473 my $done = AnyEvent->condvar;
476 474
475 # this forks and immediately calls exit in the child. this
476 # normally has all sorts of bad consequences for your parent,
477 # so take this as an example only. always fork and exec,
478 # or call POSIX::_exit, in real code.
477 my $pid = fork or exit 5; 479 my $pid = fork or exit 5;
478 480
479 my $w = AnyEvent->child ( 481 my $w = AnyEvent->child (
480 pid => $pid, 482 pid => $pid,
481 cb => sub { 483 cb => sub {
482 my ($pid, $status) = @_; 484 my ($pid, $status) = @_;
483 warn "pid $pid exited with status $status"; 485 warn "pid $pid exited with status $status";
484 $done->send; 486 $done->send;
485 }, 487 },
486 ); 488 );
487 489
488 # do something else, then wait for process exit 490 # do something else, then wait for process exit
489 $done->recv; 491 $done->recv;
490 492
491 IDLE WATCHERS 493 IDLE WATCHERS
492 $w = AnyEvent->idle (cb => <callback>); 494 $w = AnyEvent->idle (cb => <callback>);
493 495
494 Repeatedly invoke the callback after the process becomes idle, until 496 This will repeatedly invoke the callback after the process becomes idle,
495 either the watcher is destroyed or new events have been detected. 497 until either the watcher is destroyed or new events have been detected.
496 498
497 Idle watchers are useful when there is a need to do something, but it is 499 Idle watchers are useful when there is a need to do something, but it is
498 not so important (or wise) to do it instantly. The callback will be 500 not so important (or wise) to do it instantly. The callback will be
499 invoked only when there is "nothing better to do", which is usually 501 invoked only when there is "nothing better to do", which is usually
500 defined as "all outstanding events have been handled and no new events 502 defined as "all outstanding events have been handled and no new events
539 541
540 AnyEvent is slightly different: it expects somebody else to run the 542 AnyEvent is slightly different: it expects somebody else to run the
541 event loop and will only block when necessary (usually when told by the 543 event loop and will only block when necessary (usually when told by the
542 user). 544 user).
543 545
544 The instrument to do that is called a "condition variable", so called 546 The tool to do that is called a "condition variable", so called because
545 because they represent a condition that must become true. 547 they represent a condition that must become true.
546 548
547 Now is probably a good time to look at the examples further below. 549 Now is probably a good time to look at the examples further below.
548 550
549 Condition variables can be created by calling the "AnyEvent->condvar" 551 Condition variables can be created by calling the "AnyEvent->condvar"
550 method, usually without arguments. The only argument pair allowed is 552 method, usually without arguments. The only argument pair allowed is
555 After creation, the condition variable is "false" until it becomes 557 After creation, the condition variable is "false" until it becomes
556 "true" by calling the "send" method (or calling the condition variable 558 "true" by calling the "send" method (or calling the condition variable
557 as if it were a callback, read about the caveats in the description for 559 as if it were a callback, read about the caveats in the description for
558 the "->send" method). 560 the "->send" method).
559 561
560 Condition variables are similar to callbacks, except that you can 562 Since condition variables are the most complex part of the AnyEvent API,
561 optionally wait for them. They can also be called merge points - points 563 here are some different mental models of what they are - pick the ones
562 in time where multiple outstanding events have been processed. And yet 564 you can connect to:
563 another way to call them is transactions - each condition variable can 565
564 be used to represent a transaction, which finishes at some point and 566 * Condition variables are like callbacks - you can call them (and pass
565 delivers a result. And yet some people know them as "futures" - a 567 them instead of callbacks). Unlike callbacks however, you can also
566 promise to compute/deliver something that you can wait for. 568 wait for them to be called.
569
570 * Condition variables are signals - one side can emit or send them,
571 the other side can wait for them, or install a handler that is
572 called when the signal fires.
573
574 * Condition variables are like "Merge Points" - points in your program
575 where you merge multiple independent results/control flows into one.
576
577 * Condition variables represent a transaction - functions that start
578 some kind of transaction can return them, leaving the caller the
579 choice between waiting in a blocking fashion, or setting a callback.
580
581 * Condition variables represent future values, or promises to deliver
582 some result, long before the result is available.
567 583
568 Condition variables are very useful to signal that something has 584 Condition variables are very useful to signal that something has
569 finished, for example, if you write a module that does asynchronous http 585 finished, for example, if you write a module that does asynchronous http
570 requests, then a condition variable would be the ideal candidate to 586 requests, then a condition variable would be the ideal candidate to
571 signal the availability of results. The user can either act when the 587 signal the availability of results. The user can either act when the
584 600
585 Condition variables are represented by hash refs in perl, and the keys 601 Condition variables are represented by hash refs in perl, and the keys
586 used by AnyEvent itself are all named "_ae_XXX" to make subclassing easy 602 used by AnyEvent itself are all named "_ae_XXX" to make subclassing easy
587 (it is often useful to build your own transaction class on top of 603 (it is often useful to build your own transaction class on top of
588 AnyEvent). To subclass, use "AnyEvent::CondVar" as base class and call 604 AnyEvent). To subclass, use "AnyEvent::CondVar" as base class and call
589 it's "new" method in your own "new" method. 605 its "new" method in your own "new" method.
590 606
591 There are two "sides" to a condition variable - the "producer side" 607 There are two "sides" to a condition variable - the "producer side"
592 which eventually calls "-> send", and the "consumer side", which waits 608 which eventually calls "-> send", and the "consumer side", which waits
593 for the send to occur. 609 for the send to occur.
594 610
654 Condition variables are overloaded so one can call them directly (as 670 Condition variables are overloaded so one can call them directly (as
655 if they were a code reference). Calling them directly is the same as 671 if they were a code reference). Calling them directly is the same as
656 calling "send". 672 calling "send".
657 673
658 $cv->croak ($error) 674 $cv->croak ($error)
659 Similar to send, but causes all call's to "->recv" to invoke 675 Similar to send, but causes all calls to "->recv" to invoke
660 "Carp::croak" with the given error message/object/scalar. 676 "Carp::croak" with the given error message/object/scalar.
661 677
662 This can be used to signal any errors to the condition variable 678 This can be used to signal any errors to the condition variable
663 user/consumer. Doing it this way instead of calling "croak" directly 679 user/consumer. Doing it this way instead of calling "croak" directly
664 delays the error detetcion, but has the overwhelmign advantage that 680 delays the error detection, but has the overwhelming advantage that
665 it diagnoses the error at the place where the result is expected, 681 it diagnoses the error at the place where the result is expected,
666 and not deep in some event clalback without connection to the actual 682 and not deep in some event callback with no connection to the actual
667 code causing the problem. 683 code causing the problem.
668 684
669 $cv->begin ([group callback]) 685 $cv->begin ([group callback])
670 $cv->end 686 $cv->end
671 These two methods can be used to combine many transactions/events 687 These two methods can be used to combine many transactions/events
707 This works because for every event source (EOF on file handle), 723 This works because for every event source (EOF on file handle),
708 there is one call to "begin", so the condvar waits for all calls to 724 there is one call to "begin", so the condvar waits for all calls to
709 "end" before sending. 725 "end" before sending.
710 726
711 The ping example mentioned above is slightly more complicated, as 727 The ping example mentioned above is slightly more complicated, as
712 the there are results to be passwd back, and the number of tasks 728 the there are results to be passed back, and the number of tasks
713 that are begung can potentially be zero: 729 that are begun can potentially be zero:
714 730
715 my $cv = AnyEvent->condvar; 731 my $cv = AnyEvent->condvar;
716 732
717 my %result; 733 my %result;
718 $cv->begin (sub { shift->send (\%result) }); 734 $cv->begin (sub { shift->send (\%result) });
725 }; 741 };
726 } 742 }
727 743
728 $cv->end; 744 $cv->end;
729 745
746 ...
747
748 my $results = $cv->recv;
749
730 This code fragment supposedly pings a number of hosts and calls 750 This code fragment supposedly pings a number of hosts and calls
731 "send" after results for all then have have been gathered - in any 751 "send" after results for all then have have been gathered - in any
732 order. To achieve this, the code issues a call to "begin" when it 752 order. To achieve this, the code issues a call to "begin" when it
733 starts each ping request and calls "end" when it has received some 753 starts each ping request and calls "end" when it has received some
734 result for it. Since "begin" and "end" only maintain a counter, the 754 result for it. Since "begin" and "end" only maintain a counter, the
739 callback to be called once the counter reaches 0, and second, it 759 callback to be called once the counter reaches 0, and second, it
740 ensures that "send" is called even when "no" hosts are being pinged 760 ensures that "send" is called even when "no" hosts are being pinged
741 (the loop doesn't execute once). 761 (the loop doesn't execute once).
742 762
743 This is the general pattern when you "fan out" into multiple (but 763 This is the general pattern when you "fan out" into multiple (but
744 potentially none) subrequests: use an outer "begin"/"end" pair to 764 potentially zero) subrequests: use an outer "begin"/"end" pair to
745 set the callback and ensure "end" is called at least once, and then, 765 set the callback and ensure "end" is called at least once, and then,
746 for each subrequest you start, call "begin" and for each subrequest 766 for each subrequest you start, call "begin" and for each subrequest
747 you finish, call "end". 767 you finish, call "end".
748 768
749 METHODS FOR CONSUMERS 769 METHODS FOR CONSUMERS
750 These methods should only be used by the consuming side, i.e. the code 770 These methods should only be used by the consuming side, i.e. the code
751 awaits the condition. 771 awaits the condition.
752 772
753 $cv->recv 773 $cv->recv
754 Wait (blocking if necessary) until the "->send" or "->croak" methods 774 Wait (blocking if necessary) until the "->send" or "->croak" methods
755 have been called on c<$cv>, while servicing other watchers normally. 775 have been called on $cv, while servicing other watchers normally.
756 776
757 You can only wait once on a condition - additional calls are valid 777 You can only wait once on a condition - additional calls are valid
758 but will return immediately. 778 but will return immediately.
759 779
760 If an error condition has been set by calling "->croak", then this 780 If an error condition has been set by calling "->croak", then this
763 In list context, all parameters passed to "send" will be returned, 783 In list context, all parameters passed to "send" will be returned,
764 in scalar context only the first one will be returned. 784 in scalar context only the first one will be returned.
765 785
766 Note that doing a blocking wait in a callback is not supported by 786 Note that doing a blocking wait in a callback is not supported by
767 any event loop, that is, recursive invocation of a blocking "->recv" 787 any event loop, that is, recursive invocation of a blocking "->recv"
768 is not allowed, and the "recv" call will "croak" if such a condition 788 is not allowed and the "recv" call will "croak" if such a condition
769 is detected. This condition can be slightly loosened by using 789 is detected. This requirement can be dropped by relying on
770 Coro::AnyEvent, which allows you to do a blocking "->recv" from any 790 Coro::AnyEvent , which allows you to do a blocking "->recv" from any
771 thread that doesn't run the event loop itself. 791 thread that doesn't run the event loop itself. Coro::AnyEvent is
792 loaded automatically when Coro is used with AnyEvent, so code does
793 not need to do anything special to take advantage of that: any code
794 that would normally block your program because it calls "recv", be
795 executed in an "async" thread instead without blocking other
796 threads.
772 797
773 Not all event models support a blocking wait - some die in that case 798 Not all event models support a blocking wait - some die in that case
774 (programs might want to do that to stay interactive), so *if you are 799 (programs might want to do that to stay interactive), so *if you are
775 using this from a module, never require a blocking wait*. Instead, 800 using this from a module, never require a blocking wait*. Instead,
776 let the caller decide whether the call will block or not (for 801 let the caller decide whether the call will block or not (for
777 example, by coupling condition variables with some kind of request 802 example, by coupling condition variables with some kind of request
778 results and supporting callbacks so the caller knows that getting 803 results and supporting callbacks so the caller knows that getting
779 the result will not block, while still supporting blocking waits if 804 the result will not block, while still supporting blocking waits if
780 the caller so desires). 805 the caller so desires).
781 806
782 You can ensure that "-recv" never blocks by setting a callback and 807 You can ensure that "->recv" never blocks by setting a callback and
783 only calling "->recv" from within that callback (or at a later 808 only calling "->recv" from within that callback (or at a later
784 time). This will work even when the event loop does not support 809 time). This will work even when the event loop does not support
785 blocking waits otherwise. 810 blocking waits otherwise.
786 811
787 $bool = $cv->ready 812 $bool = $cv->ready
790 815
791 $cb = $cv->cb ($cb->($cv)) 816 $cb = $cv->cb ($cb->($cv))
792 This is a mutator function that returns the callback set and 817 This is a mutator function that returns the callback set and
793 optionally replaces it before doing so. 818 optionally replaces it before doing so.
794 819
795 The callback will be called when the condition becomes (or already 820 The callback will be called when the condition becomes "true", i.e.
796 was) "true", i.e. when "send" or "croak" are called (or were 821 when "send" or "croak" are called, with the only argument being the
797 called), with the only argument being the condition variable itself. 822 condition variable itself. If the condition is already true, the
798 Calling "recv" inside the callback or at any later time is 823 callback is called immediately when it is set. Calling "recv" inside
799 guaranteed not to block. 824 the callback or at any later time is guaranteed not to block.
800 825
801SUPPORTED EVENT LOOPS/BACKENDS 826SUPPORTED EVENT LOOPS/BACKENDS
802 The available backend classes are (every class has its own manpage): 827 The available backend classes are (every class has its own manpage):
803 828
804 Backends that are autoprobed when no other event loop can be found. 829 Backends that are autoprobed when no other event loop can be found.
806 use. If EV is not installed, then AnyEvent will fall back to its own 831 use. If EV is not installed, then AnyEvent will fall back to its own
807 pure-perl implementation, which is available everywhere as it comes 832 pure-perl implementation, which is available everywhere as it comes
808 with AnyEvent itself. 833 with AnyEvent itself.
809 834
810 AnyEvent::Impl::EV based on EV (interface to libev, best choice). 835 AnyEvent::Impl::EV based on EV (interface to libev, best choice).
811 AnyEvent::Impl::Perl pure-perl implementation, fast and portable. 836 AnyEvent::Impl::Perl pure-perl AnyEvent::Loop, fast and portable.
812 837
813 Backends that are transparently being picked up when they are used. 838 Backends that are transparently being picked up when they are used.
814 These will be used when they are currently loaded when the first 839 These will be used if they are already loaded when the first watcher
815 watcher is created, in which case it is assumed that the application 840 is created, in which case it is assumed that the application is
816 is using them. This means that AnyEvent will automatically pick the 841 using them. This means that AnyEvent will automatically pick the
817 right backend when the main program loads an event module before 842 right backend when the main program loads an event module before
818 anything starts to create watchers. Nothing special needs to be done 843 anything starts to create watchers. Nothing special needs to be done
819 by the main program. 844 by the main program.
820 845
821 AnyEvent::Impl::Event based on Event, very stable, few glitches. 846 AnyEvent::Impl::Event based on Event, very stable, few glitches.
822 AnyEvent::Impl::Glib based on Glib, slow but very stable. 847 AnyEvent::Impl::Glib based on Glib, slow but very stable.
823 AnyEvent::Impl::Tk based on Tk, very broken. 848 AnyEvent::Impl::Tk based on Tk, very broken.
849 AnyEvent::Impl::UV based on UV, innovated square wheels.
824 AnyEvent::Impl::EventLib based on Event::Lib, leaks memory and worse. 850 AnyEvent::Impl::EventLib based on Event::Lib, leaks memory and worse.
825 AnyEvent::Impl::POE based on POE, very slow, some limitations. 851 AnyEvent::Impl::POE based on POE, very slow, some limitations.
826 AnyEvent::Impl::Irssi used when running within irssi. 852 AnyEvent::Impl::Irssi used when running within irssi.
853 AnyEvent::Impl::IOAsync based on IO::Async.
854 AnyEvent::Impl::Cocoa based on Cocoa::EventLoop.
855 AnyEvent::Impl::FLTK based on FLTK (fltk 2 binding).
827 856
828 Backends with special needs. 857 Backends with special needs.
829 Qt requires the Qt::Application to be instantiated first, but will 858 Qt requires the Qt::Application to be instantiated first, but will
830 otherwise be picked up automatically. As long as the main program 859 otherwise be picked up automatically. As long as the main program
831 instantiates the application before any AnyEvent watchers are 860 instantiates the application before any AnyEvent watchers are
832 created, everything should just work. 861 created, everything should just work.
833 862
834 AnyEvent::Impl::Qt based on Qt. 863 AnyEvent::Impl::Qt based on Qt.
835 864
836 Support for IO::Async can only be partial, as it is too broken and
837 architecturally limited to even support the AnyEvent API. It also is
838 the only event loop that needs the loop to be set explicitly, so it
839 can only be used by a main program knowing about AnyEvent. See
840 AnyEvent::Impl::Async for the gory details.
841
842 AnyEvent::Impl::IOAsync based on IO::Async, cannot be autoprobed.
843
844 Event loops that are indirectly supported via other backends. 865 Event loops that are indirectly supported via other backends.
845 Some event loops can be supported via other modules: 866 Some event loops can be supported via other modules:
846 867
847 There is no direct support for WxWidgets (Wx) or Prima. 868 There is no direct support for WxWidgets (Wx) or Prima.
848 869
866 Contains "undef" until the first watcher is being created, before 887 Contains "undef" until the first watcher is being created, before
867 the backend has been autodetected. 888 the backend has been autodetected.
868 889
869 Afterwards it contains the event model that is being used, which is 890 Afterwards it contains the event model that is being used, which is
870 the name of the Perl class implementing the model. This class is 891 the name of the Perl class implementing the model. This class is
871 usually one of the "AnyEvent::Impl:xxx" modules, but can be any 892 usually one of the "AnyEvent::Impl::xxx" modules, but can be any
872 other class in the case AnyEvent has been extended at runtime (e.g. 893 other class in the case AnyEvent has been extended at runtime (e.g.
873 in *rxvt-unicode* it will be "urxvt::anyevent"). 894 in *rxvt-unicode* it will be "urxvt::anyevent").
874 895
875 AnyEvent::detect 896 AnyEvent::detect
876 Returns $AnyEvent::MODEL, forcing autodetection of the event model 897 Returns $AnyEvent::MODEL, forcing autodetection of the event model
877 if necessary. You should only call this function right before you 898 if necessary. You should only call this function right before you
878 would have created an AnyEvent watcher anyway, that is, as late as 899 would have created an AnyEvent watcher anyway, that is, as late as
879 possible at runtime, and not e.g. while initialising of your module. 900 possible at runtime, and not e.g. during initialisation of your
901 module.
902
903 The effect of calling this function is as if a watcher had been
904 created (specifically, actions that happen "when the first watcher
905 is created" happen when calling detetc as well).
880 906
881 If you need to do some initialisation before AnyEvent watchers are 907 If you need to do some initialisation before AnyEvent watchers are
882 created, use "post_detect". 908 created, use "post_detect".
883 909
884 $guard = AnyEvent::post_detect { BLOCK } 910 $guard = AnyEvent::post_detect { BLOCK }
885 Arranges for the code block to be executed as soon as the event 911 Arranges for the code block to be executed as soon as the event
886 model is autodetected (or immediately if this has already happened). 912 model is autodetected (or immediately if that has already happened).
887 913
888 The block will be executed *after* the actual backend has been 914 The block will be executed *after* the actual backend has been
889 detected ($AnyEvent::MODEL is set), but *before* any watchers have 915 detected ($AnyEvent::MODEL is set), but *before* any watchers have
890 been created, so it is possible to e.g. patch @AnyEvent::ISA or do 916 been created, so it is possible to e.g. patch @AnyEvent::ISA or do
891 other initialisations - see the sources of AnyEvent::Strict or 917 other initialisations - see the sources of AnyEvent::Strict or
900 object that automatically removes the callback again when it is 926 object that automatically removes the callback again when it is
901 destroyed (or "undef" when the hook was immediately executed). See 927 destroyed (or "undef" when the hook was immediately executed). See
902 AnyEvent::AIO for a case where this is useful. 928 AnyEvent::AIO for a case where this is useful.
903 929
904 Example: Create a watcher for the IO::AIO module and store it in 930 Example: Create a watcher for the IO::AIO module and store it in
905 $WATCHER. Only do so after the event loop is initialised, though. 931 $WATCHER, but do so only do so after the event loop is initialised.
906 932
907 our WATCHER; 933 our WATCHER;
908 934
909 my $guard = AnyEvent::post_detect { 935 my $guard = AnyEvent::post_detect {
910 $WATCHER = AnyEvent->io (fh => IO::AIO::poll_fileno, poll => 'r', cb => \&IO::AIO::poll_cb); 936 $WATCHER = AnyEvent->io (fh => IO::AIO::poll_fileno, poll => 'r', cb => \&IO::AIO::poll_cb);
917 943
918 $WATCHER ||= $guard; 944 $WATCHER ||= $guard;
919 945
920 @AnyEvent::post_detect 946 @AnyEvent::post_detect
921 If there are any code references in this array (you can "push" to it 947 If there are any code references in this array (you can "push" to it
922 before or after loading AnyEvent), then they will called directly 948 before or after loading AnyEvent), then they will be called directly
923 after the event loop has been chosen. 949 after the event loop has been chosen.
924 950
925 You should check $AnyEvent::MODEL before adding to this array, 951 You should check $AnyEvent::MODEL before adding to this array,
926 though: if it is defined then the event loop has already been 952 though: if it is defined then the event loop has already been
927 detected, and the array will be ignored. 953 detected, and the array will be ignored.
946 # AnyEvent not yet initialised, so make sure to load Coro::AnyEvent 972 # AnyEvent not yet initialised, so make sure to load Coro::AnyEvent
947 # as soon as it is 973 # as soon as it is
948 push @AnyEvent::post_detect, sub { require Coro::AnyEvent }; 974 push @AnyEvent::post_detect, sub { require Coro::AnyEvent };
949 } 975 }
950 976
977 AnyEvent::postpone { BLOCK }
978 Arranges for the block to be executed as soon as possible, but not
979 before the call itself returns. In practise, the block will be
980 executed just before the event loop polls for new events, or shortly
981 afterwards.
982
983 This function never returns anything (to make the "return postpone {
984 ... }" idiom more useful.
985
986 To understand the usefulness of this function, consider a function
987 that asynchronously does something for you and returns some
988 transaction object or guard to let you cancel the operation. For
989 example, "AnyEvent::Socket::tcp_connect":
990
991 # start a connection attempt unless one is active
992 $self->{connect_guard} ||= AnyEvent::Socket::tcp_connect "www.example.net", 80, sub {
993 delete $self->{connect_guard};
994 ...
995 };
996
997 Imagine that this function could instantly call the callback, for
998 example, because it detects an obvious error such as a negative port
999 number. Invoking the callback before the function returns causes
1000 problems however: the callback will be called and will try to delete
1001 the guard object. But since the function hasn't returned yet, there
1002 is nothing to delete. When the function eventually returns it will
1003 assign the guard object to "$self->{connect_guard}", where it will
1004 likely never be deleted, so the program thinks it is still trying to
1005 connect.
1006
1007 This is where "AnyEvent::postpone" should be used. Instead of
1008 calling the callback directly on error:
1009
1010 $cb->(undef), return # signal error to callback, BAD!
1011 if $some_error_condition;
1012
1013 It should use "postpone":
1014
1015 AnyEvent::postpone { $cb->(undef) }, return # signal error to callback, later
1016 if $some_error_condition;
1017
1018 AnyEvent::log $level, $msg[, @args]
1019 Log the given $msg at the given $level.
1020
1021 If AnyEvent::Log is not loaded then this function makes a simple
1022 test to see whether the message will be logged. If the test succeeds
1023 it will load AnyEvent::Log and call "AnyEvent::Log::log" -
1024 consequently, look at the AnyEvent::Log documentation for details.
1025
1026 If the test fails it will simply return. Right now this happens when
1027 a numerical loglevel is used and it is larger than the level
1028 specified via $ENV{PERL_ANYEVENT_VERBOSE}.
1029
1030 If you want to sprinkle loads of logging calls around your code,
1031 consider creating a logger callback with the "AnyEvent::Log::logger"
1032 function, which can reduce typing, codesize and can reduce the
1033 logging overhead enourmously.
1034
951WHAT TO DO IN A MODULE 1035WHAT TO DO IN A MODULE
952 As a module author, you should "use AnyEvent" and call AnyEvent methods 1036 As a module author, you should "use AnyEvent" and call AnyEvent methods
953 freely, but you should not load a specific event module or rely on it. 1037 freely, but you should not load a specific event module or rely on it.
954 1038
955 Be careful when you create watchers in the module body - AnyEvent will 1039 Be careful when you create watchers in the module body - AnyEvent will
962 stall the whole program, and the whole point of using events is to stay 1046 stall the whole program, and the whole point of using events is to stay
963 interactive. 1047 interactive.
964 1048
965 It is fine, however, to call "->recv" when the user of your module 1049 It is fine, however, to call "->recv" when the user of your module
966 requests it (i.e. if you create a http request object ad have a method 1050 requests it (i.e. if you create a http request object ad have a method
967 called "results" that returns the results, it should call "->recv" 1051 called "results" that returns the results, it may call "->recv" freely,
968 freely, as the user of your module knows what she is doing. always). 1052 as the user of your module knows what she is doing. Always).
969 1053
970WHAT TO DO IN THE MAIN PROGRAM 1054WHAT TO DO IN THE MAIN PROGRAM
971 There will always be a single main program - the only place that should 1055 There will always be a single main program - the only place that should
972 dictate which event model to use. 1056 dictate which event model to use.
973 1057
974 If it doesn't care, it can just "use AnyEvent" and use it itself, or not 1058 If the program is not event-based, it need not do anything special, even
975 do anything special (it does not need to be event-based) and let 1059 when it depends on a module that uses an AnyEvent. If the program itself
976 AnyEvent decide which implementation to chose if some module relies on 1060 uses AnyEvent, but does not care which event loop is used, all it needs
977 it. 1061 to do is "use AnyEvent". In either case, AnyEvent will choose the best
1062 available loop implementation.
978 1063
979 If the main program relies on a specific event model - for example, in 1064 If the main program relies on a specific event model - for example, in
980 Gtk2 programs you have to rely on the Glib module - you should load the 1065 Gtk2 programs you have to rely on the Glib module - you should load the
981 event module before loading AnyEvent or any module that uses it: 1066 event module before loading AnyEvent or any module that uses it:
982 generally speaking, you should load it as early as possible. The reason 1067 generally speaking, you should load it as early as possible. The reason
983 is that modules might create watchers when they are loaded, and AnyEvent 1068 is that modules might create watchers when they are loaded, and AnyEvent
984 will decide on the event model to use as soon as it creates watchers, 1069 will decide on the event model to use as soon as it creates watchers,
985 and it might chose the wrong one unless you load the correct one 1070 and it might choose the wrong one unless you load the correct one
986 yourself. 1071 yourself.
987 1072
988 You can chose to use a pure-perl implementation by loading the 1073 You can chose to use a pure-perl implementation by loading the
989 "AnyEvent::Impl::Perl" module, which gives you similar behaviour 1074 "AnyEvent::Loop" module, which gives you similar behaviour everywhere,
990 everywhere, but letting AnyEvent chose the model is generally better. 1075 but letting AnyEvent chose the model is generally better.
991 1076
992 MAINLOOP EMULATION 1077 MAINLOOP EMULATION
993 Sometimes (often for short test scripts, or even standalone programs who 1078 Sometimes (often for short test scripts, or even standalone programs who
994 only want to use AnyEvent), you do not want to run a specific event 1079 only want to use AnyEvent), you do not want to run a specific event
995 loop. 1080 loop.
1007 1092
1008OTHER MODULES 1093OTHER MODULES
1009 The following is a non-exhaustive list of additional modules that use 1094 The following is a non-exhaustive list of additional modules that use
1010 AnyEvent as a client and can therefore be mixed easily with other 1095 AnyEvent as a client and can therefore be mixed easily with other
1011 AnyEvent modules and other event loops in the same program. Some of the 1096 AnyEvent modules and other event loops in the same program. Some of the
1012 modules come with AnyEvent, most are available via CPAN. 1097 modules come as part of AnyEvent, the others are available via CPAN (see
1098 <http://search.cpan.org/search?m=module&q=anyevent%3A%3A*> for a longer
1099 non-exhaustive list), and the list is heavily biased towards modules of
1100 the AnyEvent author himself :)
1013 1101
1014 AnyEvent::Util 1102 AnyEvent::Util (part of the AnyEvent distribution)
1015 Contains various utility functions that replace often-used but 1103 Contains various utility functions that replace often-used blocking
1016 blocking functions such as "inet_aton" by event-/callback-based 1104 functions such as "inet_aton" with event/callback-based versions.
1017 versions.
1018 1105
1019 AnyEvent::Socket 1106 AnyEvent::Socket (part of the AnyEvent distribution)
1020 Provides various utility functions for (internet protocol) sockets, 1107 Provides various utility functions for (internet protocol) sockets,
1021 addresses and name resolution. Also functions to create non-blocking 1108 addresses and name resolution. Also functions to create non-blocking
1022 tcp connections or tcp servers, with IPv6 and SRV record support and 1109 tcp connections or tcp servers, with IPv6 and SRV record support and
1023 more. 1110 more.
1024 1111
1025 AnyEvent::Handle 1112 AnyEvent::Handle (part of the AnyEvent distribution)
1026 Provide read and write buffers, manages watchers for reads and 1113 Provide read and write buffers, manages watchers for reads and
1027 writes, supports raw and formatted I/O, I/O queued and fully 1114 writes, supports raw and formatted I/O, I/O queued and fully
1028 transparent and non-blocking SSL/TLS (via AnyEvent::TLS. 1115 transparent and non-blocking SSL/TLS (via AnyEvent::TLS).
1029 1116
1030 AnyEvent::DNS 1117 AnyEvent::DNS (part of the AnyEvent distribution)
1031 Provides rich asynchronous DNS resolver capabilities. 1118 Provides rich asynchronous DNS resolver capabilities.
1032 1119
1033 AnyEvent::HTTP 1120 AnyEvent::HTTP, AnyEvent::IRC, AnyEvent::XMPP, AnyEvent::GPSD,
1034 A simple-to-use HTTP library that is capable of making a lot of 1121 AnyEvent::IGS, AnyEvent::FCP
1035 concurrent HTTP requests. 1122 Implement event-based interfaces to the protocols of the same name
1123 (for the curious, IGS is the International Go Server and FCP is the
1124 Freenet Client Protocol).
1036 1125
1126 AnyEvent::AIO (part of the AnyEvent distribution)
1127 Truly asynchronous (as opposed to non-blocking) I/O, should be in
1128 the toolbox of every event programmer. AnyEvent::AIO transparently
1129 fuses IO::AIO and AnyEvent together, giving AnyEvent access to
1130 event-based file I/O, and much more.
1131
1132 AnyEvent::Fork, AnyEvent::Fork::RPC, AnyEvent::Fork::Pool,
1133 AnyEvent::Fork::Remote
1134 These let you safely fork new subprocesses, either locally or
1135 remotely (e.g.v ia ssh), using some RPC protocol or not, without the
1136 limitations normally imposed by fork (AnyEvent works fine for
1137 example). Dynamically-resized worker pools are obviously included as
1138 well.
1139
1140 And they are quite tiny and fast as well - "abusing" AnyEvent::Fork
1141 just to exec external programs can easily beat using "fork" and
1142 "exec" (or even "system") in most programs.
1143
1144 AnyEvent::Filesys::Notify
1145 AnyEvent is good for non-blocking stuff, but it can't detect file or
1146 path changes (e.g. "watch this directory for new files", "watch this
1147 file for changes"). The AnyEvent::Filesys::Notify module promises to
1148 do just that in a portbale fashion, supporting inotify on GNU/Linux
1149 and some weird, without doubt broken, stuff on OS X to monitor
1150 files. It can fall back to blocking scans at regular intervals
1151 transparently on other platforms, so it's about as portable as it
1152 gets.
1153
1154 (I haven't used it myself, but it seems the biggest problem with it
1155 is it quite bad performance).
1156
1037 AnyEvent::HTTPD 1157 AnyEvent::DBI
1038 Provides a simple web application server framework. 1158 Executes DBI requests asynchronously in a proxy process for you,
1159 notifying you in an event-based way when the operation is finished.
1039 1160
1040 AnyEvent::FastPing 1161 AnyEvent::FastPing
1041 The fastest ping in the west. 1162 The fastest ping in the west.
1042 1163
1043 AnyEvent::DBI
1044 Executes DBI requests asynchronously in a proxy process.
1045
1046 AnyEvent::AIO
1047 Truly asynchronous I/O, should be in the toolbox of every event
1048 programmer. AnyEvent::AIO transparently fuses IO::AIO and AnyEvent
1049 together.
1050
1051 AnyEvent::BDB
1052 Truly asynchronous Berkeley DB access. AnyEvent::BDB transparently
1053 fuses BDB and AnyEvent together.
1054
1055 AnyEvent::GPSD
1056 A non-blocking interface to gpsd, a daemon delivering GPS
1057 information.
1058
1059 AnyEvent::IRC
1060 AnyEvent based IRC client module family (replacing the older
1061 Net::IRC3).
1062
1063 AnyEvent::XMPP
1064 AnyEvent based XMPP (Jabber protocol) module family (replacing the
1065 older Net::XMPP2>.
1066
1067 AnyEvent::IGS
1068 A non-blocking interface to the Internet Go Server protocol (used by
1069 App::IGS).
1070
1071 Net::FCP
1072 AnyEvent-based implementation of the Freenet Client Protocol,
1073 birthplace of AnyEvent.
1074
1075 Event::ExecFlow
1076 High level API for event-based execution flow control.
1077
1078 Coro 1164 Coro
1079 Has special support for AnyEvent via Coro::AnyEvent. 1165 Has special support for AnyEvent via Coro::AnyEvent, which allows
1166 you to simply invert the flow control - don't call us, we will call
1167 you:
1168
1169 async {
1170 Coro::AnyEvent::sleep 5; # creates a 5s timer and waits for it
1171 print "5 seconds later!\n";
1172
1173 Coro::AnyEvent::readable *STDIN; # uses an I/O watcher
1174 my $line = <STDIN>; # works for ttys
1175
1176 AnyEvent::HTTP::http_get "url", Coro::rouse_cb;
1177 my ($body, $hdr) = Coro::rouse_wait;
1178 };
1080 1179
1081SIMPLIFIED AE API 1180SIMPLIFIED AE API
1082 Starting with version 5.0, AnyEvent officially supports a second, much 1181 Starting with version 5.0, AnyEvent officially supports a second, much
1083 simpler, API that is designed to reduce the calling, typing and memory 1182 simpler, API that is designed to reduce the calling, typing and memory
1084 overhead by using function call syntax and a fixed number of parameters. 1183 overhead by using function call syntax and a fixed number of parameters.
1100 The pure perl event loop simply re-throws the exception (usually within 1199 The pure perl event loop simply re-throws the exception (usually within
1101 "condvar->recv"), the Event and EV modules call "$Event/EV::DIED->()", 1200 "condvar->recv"), the Event and EV modules call "$Event/EV::DIED->()",
1102 Glib uses "install_exception_handler" and so on. 1201 Glib uses "install_exception_handler" and so on.
1103 1202
1104ENVIRONMENT VARIABLES 1203ENVIRONMENT VARIABLES
1105 The following environment variables are used by this module or its 1204 AnyEvent supports a number of environment variables that tune the
1106 submodules. 1205 runtime behaviour. They are usually evaluated when AnyEvent is loaded,
1206 initialised, or a submodule that uses them is loaded. Many of them also
1207 cause AnyEvent to load additional modules - for example,
1208 "PERL_ANYEVENT_DEBUG_WRAP" causes the AnyEvent::Debug module to be
1209 loaded.
1107 1210
1108 Note that AnyEvent will remove *all* environment variables starting with 1211 All the environment variables documented here start with
1109 "PERL_ANYEVENT_" from %ENV when it is loaded while taint mode is 1212 "PERL_ANYEVENT_", which is what AnyEvent considers its own namespace.
1110 enabled. 1213 Other modules are encouraged (but by no means required) to use
1214 "PERL_ANYEVENT_SUBMODULE" if they have registered the
1215 AnyEvent::Submodule namespace on CPAN, for any submodule. For example,
1216 AnyEvent::HTTP could be expected to use "PERL_ANYEVENT_HTTP_PROXY" (it
1217 should not access env variables starting with "AE_", see below).
1218
1219 All variables can also be set via the "AE_" prefix, that is, instead of
1220 setting "PERL_ANYEVENT_VERBOSE" you can also set "AE_VERBOSE". In case
1221 there is a clash btween anyevent and another program that uses
1222 "AE_something" you can set the corresponding "PERL_ANYEVENT_something"
1223 variable to the empty string, as those variables take precedence.
1224
1225 When AnyEvent is first loaded, it copies all "AE_xxx" env variables to
1226 their "PERL_ANYEVENT_xxx" counterpart unless that variable already
1227 exists. If taint mode is on, then AnyEvent will remove *all* environment
1228 variables starting with "PERL_ANYEVENT_" from %ENV (or replace them with
1229 "undef" or the empty string, if the corresaponding "AE_" variable is
1230 set).
1231
1232 The exact algorithm is currently:
1233
1234 1. if taint mode enabled, delete all PERL_ANYEVENT_xyz variables from %ENV
1235 2. copy over AE_xyz to PERL_ANYEVENT_xyz unless the latter alraedy exists
1236 3. if taint mode enabled, set all PERL_ANYEVENT_xyz variables to undef.
1237
1238 This ensures that child processes will not see the "AE_" variables.
1239
1240 The following environment variables are currently known to AnyEvent:
1111 1241
1112 "PERL_ANYEVENT_VERBOSE" 1242 "PERL_ANYEVENT_VERBOSE"
1113 By default, AnyEvent will be completely silent except in fatal 1243 By default, AnyEvent will log messages with loglevel 4 ("error") or
1114 conditions. You can set this environment variable to make AnyEvent 1244 higher (see AnyEvent::Log). You can set this environment variable to
1115 more talkative. 1245 a numerical loglevel to make AnyEvent more (or less) talkative.
1116 1246
1247 If you want to do more than just set the global logging level you
1248 should have a look at "PERL_ANYEVENT_LOG", which allows much more
1249 complex specifications.
1250
1251 When set to 0 ("off"), then no messages whatsoever will be logged
1252 with everything else at defaults.
1253
1117 When set to 1 or higher, causes AnyEvent to warn about unexpected 1254 When set to 5 or higher ("warn"), AnyEvent warns about unexpected
1118 conditions, such as not being able to load the event model specified 1255 conditions, such as not being able to load the event model specified
1119 by "PERL_ANYEVENT_MODEL". 1256 by "PERL_ANYEVENT_MODEL", or a guard callback throwing an exception
1257 - this is the minimum recommended level for use during development.
1120 1258
1121 When set to 2 or higher, cause AnyEvent to report to STDERR which 1259 When set to 7 or higher (info), AnyEvent reports which event model
1122 event model it chooses. 1260 it chooses.
1123 1261
1124 When set to 8 or higher, then AnyEvent will report extra information 1262 When set to 8 or higher (debug), then AnyEvent will report extra
1125 on which optional modules it loads and how it implements certain 1263 information on which optional modules it loads and how it implements
1126 features. 1264 certain features.
1265
1266 "PERL_ANYEVENT_LOG"
1267 Accepts rather complex logging specifications. For example, you
1268 could log all "debug" messages of some module to stderr, warnings
1269 and above to stderr, and errors and above to syslog, with:
1270
1271 PERL_ANYEVENT_LOG=Some::Module=debug,+log:filter=warn,+%syslog:%syslog=error,syslog
1272
1273 For the rather extensive details, see AnyEvent::Log.
1274
1275 This variable is evaluated when AnyEvent (or AnyEvent::Log) is
1276 loaded, so will take effect even before AnyEvent has initialised
1277 itself.
1278
1279 Note that specifying this environment variable causes the
1280 AnyEvent::Log module to be loaded, while "PERL_ANYEVENT_VERBOSE"
1281 does not, so only using the latter saves a few hundred kB of memory
1282 unless a module explicitly needs the extra features of
1283 AnyEvent::Log.
1127 1284
1128 "PERL_ANYEVENT_STRICT" 1285 "PERL_ANYEVENT_STRICT"
1129 AnyEvent does not do much argument checking by default, as thorough 1286 AnyEvent does not do much argument checking by default, as thorough
1130 argument checking is very costly. Setting this variable to a true 1287 argument checking is very costly. Setting this variable to a true
1131 value will cause AnyEvent to load "AnyEvent::Strict" and then to 1288 value will cause AnyEvent to load "AnyEvent::Strict" and then to
1132 thoroughly check the arguments passed to most method calls. If it 1289 thoroughly check the arguments passed to most method calls. If it
1133 finds any problems, it will croak. 1290 finds any problems, it will croak.
1134 1291
1135 In other words, enables "strict" mode. 1292 In other words, enables "strict" mode.
1136 1293
1137 Unlike "use strict" (or it's modern cousin, "use common::sense", it 1294 Unlike "use strict" (or its modern cousin, "use common::sense", it
1138 is definitely recommended to keep it off in production. Keeping 1295 is definitely recommended to keep it off in production. Keeping
1139 "PERL_ANYEVENT_STRICT=1" in your environment while developing 1296 "PERL_ANYEVENT_STRICT=1" in your environment while developing
1140 programs can be very useful, however. 1297 programs can be very useful, however.
1141 1298
1299 "PERL_ANYEVENT_DEBUG_SHELL"
1300 If this env variable is nonempty, then its contents will be
1301 interpreted by "AnyEvent::Socket::parse_hostport" and
1302 "AnyEvent::Debug::shell" (after replacing every occurance of $$ by
1303 the process pid). The shell object is saved in
1304 $AnyEvent::Debug::SHELL.
1305
1306 This happens when the first watcher is created.
1307
1308 For example, to bind a debug shell on a unix domain socket in
1309 /tmp/debug<pid>.sock, you could use this:
1310
1311 PERL_ANYEVENT_DEBUG_SHELL=/tmp/debug\$\$.sock perlprog
1312 # connect with e.g.: socat readline /tmp/debug123.sock
1313
1314 Or to bind to tcp port 4545 on localhost:
1315
1316 PERL_ANYEVENT_DEBUG_SHELL=127.0.0.1:4545 perlprog
1317 # connect with e.g.: telnet localhost 4545
1318
1319 Note that creating sockets in /tmp or on localhost is very unsafe on
1320 multiuser systems.
1321
1322 "PERL_ANYEVENT_DEBUG_WRAP"
1323 Can be set to 0, 1 or 2 and enables wrapping of all watchers for
1324 debugging purposes. See "AnyEvent::Debug::wrap" for details.
1325
1142 "PERL_ANYEVENT_MODEL" 1326 "PERL_ANYEVENT_MODEL"
1143 This can be used to specify the event model to be used by AnyEvent, 1327 This can be used to specify the event model to be used by AnyEvent,
1144 before auto detection and -probing kicks in. It must be a string 1328 before auto detection and -probing kicks in.
1145 consisting entirely of ASCII letters. The string "AnyEvent::Impl::" 1329
1146 gets prepended and the resulting module name is loaded and if the 1330 It normally is a string consisting entirely of ASCII letters (e.g.
1147 load was successful, used as event model. If it fails to load 1331 "EV" or "IOAsync"). The string "AnyEvent::Impl::" gets prepended and
1332 the resulting module name is loaded and - if the load was successful
1333 - used as event model backend. If it fails to load then AnyEvent
1148 AnyEvent will proceed with auto detection and -probing. 1334 will proceed with auto detection and -probing.
1149 1335
1150 This functionality might change in future versions. 1336 If the string ends with "::" instead (e.g. "AnyEvent::Impl::EV::")
1337 then nothing gets prepended and the module name is used as-is (hint:
1338 "::" at the end of a string designates a module name and quotes it
1339 appropriately).
1151 1340
1152 For example, to force the pure perl model (AnyEvent::Impl::Perl) you 1341 For example, to force the pure perl model (AnyEvent::Loop::Perl) you
1153 could start your program like this: 1342 could start your program like this:
1154 1343
1155 PERL_ANYEVENT_MODEL=Perl perl ... 1344 PERL_ANYEVENT_MODEL=Perl perl ...
1345
1346 "PERL_ANYEVENT_IO_MODEL"
1347 The current file I/O model - see AnyEvent::IO for more info.
1348
1349 At the moment, only "Perl" (small, pure-perl, synchronous) and
1350 "IOAIO" (truly asynchronous) are supported. The default is "IOAIO"
1351 if AnyEvent::AIO can be loaded, otherwise it is "Perl".
1156 1352
1157 "PERL_ANYEVENT_PROTOCOLS" 1353 "PERL_ANYEVENT_PROTOCOLS"
1158 Used by both AnyEvent::DNS and AnyEvent::Socket to determine 1354 Used by both AnyEvent::DNS and AnyEvent::Socket to determine
1159 preferences for IPv4 or IPv6. The default is unspecified (and might 1355 preferences for IPv4 or IPv6. The default is unspecified (and might
1160 change, or be the result of auto probing). 1356 change, or be the result of auto probing).
1164 mentioned will be used, and preference will be given to protocols 1360 mentioned will be used, and preference will be given to protocols
1165 mentioned earlier in the list. 1361 mentioned earlier in the list.
1166 1362
1167 This variable can effectively be used for denial-of-service attacks 1363 This variable can effectively be used for denial-of-service attacks
1168 against local programs (e.g. when setuid), although the impact is 1364 against local programs (e.g. when setuid), although the impact is
1169 likely small, as the program has to handle conenction and other 1365 likely small, as the program has to handle connection and other
1170 failures anyways. 1366 failures anyways.
1171 1367
1172 Examples: "PERL_ANYEVENT_PROTOCOLS=ipv4,ipv6" - prefer IPv4 over 1368 Examples: "PERL_ANYEVENT_PROTOCOLS=ipv4,ipv6" - prefer IPv4 over
1173 IPv6, but support both and try to use both. 1369 IPv6, but support both and try to use both.
1174 "PERL_ANYEVENT_PROTOCOLS=ipv4" - only support IPv4, never try to 1370 "PERL_ANYEVENT_PROTOCOLS=ipv4" - only support IPv4, never try to
1175 resolve or contact IPv6 addresses. 1371 resolve or contact IPv6 addresses.
1176 "PERL_ANYEVENT_PROTOCOLS=ipv6,ipv4" support either IPv4 or IPv6, but 1372 "PERL_ANYEVENT_PROTOCOLS=ipv6,ipv4" support either IPv4 or IPv6, but
1177 prefer IPv6 over IPv4. 1373 prefer IPv6 over IPv4.
1178 1374
1375 "PERL_ANYEVENT_HOSTS"
1376 This variable, if specified, overrides the /etc/hosts file used by
1377 AnyEvent::Socket"::resolve_sockaddr", i.e. hosts aliases will be
1378 read from that file instead.
1379
1179 "PERL_ANYEVENT_EDNS0" 1380 "PERL_ANYEVENT_EDNS0"
1180 Used by AnyEvent::DNS to decide whether to use the EDNS0 extension 1381 Used by AnyEvent::DNS to decide whether to use the EDNS0 extension
1181 for DNS. This extension is generally useful to reduce DNS traffic, 1382 for DNS. This extension is generally useful to reduce DNS traffic,
1182 but some (broken) firewalls drop such DNS packets, which is why it 1383 especially when DNSSEC is involved, but some (broken) firewalls drop
1183 is off by default. 1384 such DNS packets, which is why it is off by default.
1184 1385
1185 Setting this variable to 1 will cause AnyEvent::DNS to announce 1386 Setting this variable to 1 will cause AnyEvent::DNS to announce
1186 EDNS0 in its DNS requests. 1387 EDNS0 in its DNS requests.
1187 1388
1188 "PERL_ANYEVENT_MAX_FORKS" 1389 "PERL_ANYEVENT_MAX_FORKS"
1192 "PERL_ANYEVENT_MAX_OUTSTANDING_DNS" 1393 "PERL_ANYEVENT_MAX_OUTSTANDING_DNS"
1193 The default value for the "max_outstanding" parameter for the 1394 The default value for the "max_outstanding" parameter for the
1194 default DNS resolver - this is the maximum number of parallel DNS 1395 default DNS resolver - this is the maximum number of parallel DNS
1195 requests that are sent to the DNS server. 1396 requests that are sent to the DNS server.
1196 1397
1398 "PERL_ANYEVENT_MAX_SIGNAL_LATENCY"
1399 Perl has inherently racy signal handling (you can basically choose
1400 between losing signals and memory corruption) - pure perl event
1401 loops (including "AnyEvent::Loop", when "Async::Interrupt" isn't
1402 available) therefore have to poll regularly to avoid losing signals.
1403
1404 Some event loops are racy, but don't poll regularly, and some event
1405 loops are written in C but are still racy. For those event loops,
1406 AnyEvent installs a timer that regularly wakes up the event loop.
1407
1408 By default, the interval for this timer is 10 seconds, but you can
1409 override this delay with this environment variable (or by setting
1410 the $AnyEvent::MAX_SIGNAL_LATENCY variable before creating signal
1411 watchers).
1412
1413 Lower values increase CPU (and energy) usage, higher values can
1414 introduce long delays when reaping children or waiting for signals.
1415
1416 The AnyEvent::Async module, if available, will be used to avoid this
1417 polling (with most event loops).
1418
1197 "PERL_ANYEVENT_RESOLV_CONF" 1419 "PERL_ANYEVENT_RESOLV_CONF"
1198 The file to use instead of /etc/resolv.conf (or OS-specific 1420 The absolute path to a resolv.conf-style file to use instead of
1199 configuration) in the default resolver. When set to the empty 1421 /etc/resolv.conf (or the OS-specific configuration) in the default
1200 string, no default config will be used. 1422 resolver, or the empty string to select the default configuration.
1201 1423
1202 "PERL_ANYEVENT_CA_FILE", "PERL_ANYEVENT_CA_PATH". 1424 "PERL_ANYEVENT_CA_FILE", "PERL_ANYEVENT_CA_PATH".
1203 When neither "ca_file" nor "ca_path" was specified during 1425 When neither "ca_file" nor "ca_path" was specified during
1204 AnyEvent::TLS context creation, and either of these environment 1426 AnyEvent::TLS context creation, and either of these environment
1205 variables exist, they will be used to specify CA certificate 1427 variables are nonempty, they will be used to specify CA certificate
1206 locations instead of a system-dependent default. 1428 locations instead of a system-dependent default.
1207 1429
1208 "PERL_ANYEVENT_AVOID_GUARD" and "PERL_ANYEVENT_AVOID_ASYNC_INTERRUPT" 1430 "PERL_ANYEVENT_AVOID_GUARD" and "PERL_ANYEVENT_AVOID_ASYNC_INTERRUPT"
1209 When these are set to 1, then the respective modules are not loaded. 1431 When these are set to 1, then the respective modules are not loaded.
1210 Mostly good for testing AnyEvent itself. 1432 Mostly good for testing AnyEvent itself.
1530 when used without AnyEvent), but most event loops have acceptable 1752 when used without AnyEvent), but most event loops have acceptable
1531 performance with or without AnyEvent. 1753 performance with or without AnyEvent.
1532 1754
1533 * The overhead AnyEvent adds is usually much smaller than the overhead 1755 * The overhead AnyEvent adds is usually much smaller than the overhead
1534 of the actual event loop, only with extremely fast event loops such 1756 of the actual event loop, only with extremely fast event loops such
1535 as EV adds AnyEvent significant overhead. 1757 as EV does AnyEvent add significant overhead.
1536 1758
1537 * You should avoid POE like the plague if you want performance or 1759 * You should avoid POE like the plague if you want performance or
1538 reasonable memory usage. 1760 reasonable memory usage.
1539 1761
1540 BENCHMARKING THE LARGE SERVER CASE 1762 BENCHMARKING THE LARGE SERVER CASE
1738 1960
1739 Feel free to install your own handler, or reset it to defaults. 1961 Feel free to install your own handler, or reset it to defaults.
1740 1962
1741RECOMMENDED/OPTIONAL MODULES 1963RECOMMENDED/OPTIONAL MODULES
1742 One of AnyEvent's main goals is to be 100% Pure-Perl(tm): only perl (and 1964 One of AnyEvent's main goals is to be 100% Pure-Perl(tm): only perl (and
1743 it's built-in modules) are required to use it. 1965 its built-in modules) are required to use it.
1744 1966
1745 That does not mean that AnyEvent won't take advantage of some additional 1967 That does not mean that AnyEvent won't take advantage of some additional
1746 modules if they are installed. 1968 modules if they are installed.
1747 1969
1748 This section explains which additional modules will be used, and how 1970 This section explains which additional modules will be used, and how
1799 worthwhile: If this module is installed, then AnyEvent::Handle (with 2021 worthwhile: If this module is installed, then AnyEvent::Handle (with
1800 the help of AnyEvent::TLS), gains the ability to do TLS/SSL. 2022 the help of AnyEvent::TLS), gains the ability to do TLS/SSL.
1801 2023
1802 Time::HiRes 2024 Time::HiRes
1803 This module is part of perl since release 5.008. It will be used 2025 This module is part of perl since release 5.008. It will be used
1804 when the chosen event library does not come with a timing source on 2026 when the chosen event library does not come with a timing source of
1805 it's own. The pure-perl event loop (AnyEvent::Impl::Perl) will 2027 its own. The pure-perl event loop (AnyEvent::Loop) will additionally
1806 additionally use it to try to use a monotonic clock for timing 2028 load it to try to use a monotonic clock for timing stability.
1807 stability. 2029
2030 AnyEvent::AIO (and IO::AIO)
2031 The default implementation of AnyEvent::IO is to do I/O
2032 synchronously, stopping programs while they access the disk, which
2033 is fine for a lot of programs.
2034
2035 Installing AnyEvent::AIO (and its IO::AIO dependency) makes it
2036 switch to a true asynchronous implementation, so event processing
2037 can continue even while waiting for disk I/O.
1808 2038
1809FORK 2039FORK
1810 Most event libraries are not fork-safe. The ones who are usually are 2040 Most event libraries are not fork-safe. The ones who are usually are
1811 because they rely on inefficient but fork-safe "select" or "poll" calls 2041 because they rely on inefficient but fork-safe "select" or "poll" calls
1812 - higher performance APIs such as BSD's kqueue or the dreaded Linux 2042 - higher performance APIs such as BSD's kqueue or the dreaded Linux
1820 usually happens when the first AnyEvent watcher is created, or the 2050 usually happens when the first AnyEvent watcher is created, or the
1821 library is loaded). 2051 library is loaded).
1822 2052
1823 If you have to fork, you must either do so *before* creating your first 2053 If you have to fork, you must either do so *before* creating your first
1824 watcher OR you must not use AnyEvent at all in the child OR you must do 2054 watcher OR you must not use AnyEvent at all in the child OR you must do
1825 something completely out of the scope of AnyEvent. 2055 something completely out of the scope of AnyEvent (see below).
1826 2056
1827 The problem of doing event processing in the parent *and* the child is 2057 The problem of doing event processing in the parent *and* the child is
1828 much more complicated: even for backends that *are* fork-aware or 2058 much more complicated: even for backends that *are* fork-aware or
1829 fork-safe, their behaviour is not usually what you want: fork clones all 2059 fork-safe, their behaviour is not usually what you want: fork clones all
1830 watchers, that means all timers, I/O watchers etc. are active in both 2060 watchers, that means all timers, I/O watchers etc. are active in both
1831 parent and child, which is almost never what you want. USing "exec" to 2061 parent and child, which is almost never what you want. Using "exec" to
1832 start worker children from some kind of manage rprocess is usually 2062 start worker children from some kind of manage prrocess is usually
1833 preferred, because it is much easier and cleaner, at the expense of 2063 preferred, because it is much easier and cleaner, at the expense of
1834 having to have another binary. 2064 having to have another binary.
2065
2066 In addition to logical problems with fork, there are also implementation
2067 problems. For example, on POSIX systems, you cannot fork at all in Perl
2068 code if a thread (I am talking of pthreads here) was ever created in the
2069 process, and this is just the tip of the iceberg. In general, using fork
2070 from Perl is difficult, and attempting to use fork without an exec to
2071 implement some kind of parallel processing is almost certainly doomed.
2072
2073 To safely fork and exec, you should use a module such as Proc::FastSpawn
2074 that let's you safely fork and exec new processes.
2075
2076 If you want to do multiprocessing using processes, you can look at the
2077 AnyEvent::Fork module (and some related modules such as
2078 AnyEvent::Fork::RPC, AnyEvent::Fork::Pool and AnyEvent::Fork::Remote).
2079 This module allows you to safely create subprocesses without any
2080 limitations - you can use X11 toolkits or AnyEvent in the children
2081 created by AnyEvent::Fork safely and without any special precautions.
1835 2082
1836SECURITY CONSIDERATIONS 2083SECURITY CONSIDERATIONS
1837 AnyEvent can be forced to load any event model via 2084 AnyEvent can be forced to load any event model via
1838 $ENV{PERL_ANYEVENT_MODEL}. While this cannot (to my knowledge) be used 2085 $ENV{PERL_ANYEVENT_MODEL}. While this cannot (to my knowledge) be used
1839 to execute arbitrary code or directly gain access, it can easily be used 2086 to execute arbitrary code or directly gain access, it can easily be used
1843 2090
1844 You can make AnyEvent completely ignore this variable by deleting it 2091 You can make AnyEvent completely ignore this variable by deleting it
1845 before the first watcher gets created, e.g. with a "BEGIN" block: 2092 before the first watcher gets created, e.g. with a "BEGIN" block:
1846 2093
1847 BEGIN { delete $ENV{PERL_ANYEVENT_MODEL} } 2094 BEGIN { delete $ENV{PERL_ANYEVENT_MODEL} }
1848 2095
1849 use AnyEvent; 2096 use AnyEvent;
1850 2097
1851 Similar considerations apply to $ENV{PERL_ANYEVENT_VERBOSE}, as that can 2098 Similar considerations apply to $ENV{PERL_ANYEVENT_VERBOSE}, as that can
1852 be used to probe what backend is used and gain other information (which 2099 be used to probe what backend is used and gain other information (which
1853 is probably even less useful to an attacker than PERL_ANYEVENT_MODEL), 2100 is probably even less useful to an attacker than PERL_ANYEVENT_MODEL),
1854 and $ENV{PERL_ANYEVENT_STRICT}. 2101 and $ENV{PERL_ANYEVENT_STRICT}.
1863 5.10 and check wether the leaks still show up. (Perl 5.10.0 has other 2110 5.10 and check wether the leaks still show up. (Perl 5.10.0 has other
1864 annoying memleaks, such as leaking on "map" and "grep" but it is usually 2111 annoying memleaks, such as leaking on "map" and "grep" but it is usually
1865 not as pronounced). 2112 not as pronounced).
1866 2113
1867SEE ALSO 2114SEE ALSO
1868 Utility functions: AnyEvent::Util. 2115 Tutorial/Introduction: AnyEvent::Intro.
1869 2116
1870 Event modules: EV, EV::Glib, Glib::EV, Event, Glib::Event, Glib, Tk, 2117 FAQ: AnyEvent::FAQ.
1871 Event::Lib, Qt, POE. 2118
2119 Utility functions: AnyEvent::Util (misc. grab-bag), AnyEvent::Log
2120 (simply logging).
2121
2122 Development/Debugging: AnyEvent::Strict (stricter checking),
2123 AnyEvent::Debug (interactive shell, watcher tracing).
2124
2125 Supported event modules: AnyEvent::Loop, EV, EV::Glib, Glib::EV, Event,
2126 Glib::Event, Glib, Tk, Event::Lib, Qt, POE, FLTK.
1872 2127
1873 Implementations: AnyEvent::Impl::EV, AnyEvent::Impl::Event, 2128 Implementations: AnyEvent::Impl::EV, AnyEvent::Impl::Event,
1874 AnyEvent::Impl::Glib, AnyEvent::Impl::Tk, AnyEvent::Impl::Perl, 2129 AnyEvent::Impl::Glib, AnyEvent::Impl::Tk, AnyEvent::Impl::Perl,
1875 AnyEvent::Impl::EventLib, AnyEvent::Impl::Qt, AnyEvent::Impl::POE, 2130 AnyEvent::Impl::EventLib, AnyEvent::Impl::Qt, AnyEvent::Impl::POE,
1876 AnyEvent::Impl::IOAsync, Anyevent::Impl::Irssi. 2131 AnyEvent::Impl::IOAsync, Anyevent::Impl::Irssi, AnyEvent::Impl::FLTK.
1877 2132
1878 Non-blocking file handles, sockets, TCP clients and servers: 2133 Non-blocking handles, pipes, stream sockets, TCP clients and servers:
1879 AnyEvent::Handle, AnyEvent::Socket, AnyEvent::TLS. 2134 AnyEvent::Handle, AnyEvent::Socket, AnyEvent::TLS.
1880 2135
2136 Asynchronous File I/O: AnyEvent::IO.
2137
1881 Asynchronous DNS: AnyEvent::DNS. 2138 Asynchronous DNS: AnyEvent::DNS.
1882 2139
1883 Coroutine support: Coro, Coro::AnyEvent, Coro::EV, Coro::Event, 2140 Thread support: Coro, Coro::AnyEvent, Coro::EV, Coro::Event.
1884 2141
1885 Nontrivial usage examples: AnyEvent::GPSD, AnyEvent::XMPP, 2142 Nontrivial usage examples: AnyEvent::GPSD, AnyEvent::IRC,
1886 AnyEvent::HTTP. 2143 AnyEvent::HTTP.
1887 2144
1888AUTHOR 2145AUTHOR
1889 Marc Lehmann <schmorp@schmorp.de> 2146 Marc Lehmann <schmorp@schmorp.de>
1890 http://home.schmorp.de/ 2147 http://anyevent.schmorp.de
1891 2148

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines