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

Comparing AnyEvent/README (file contents):
Revision 1.54 by root, Tue Sep 1 18:27:46 2009 UTC vs.
Revision 1.65 by root, Sat Aug 13 22:44:05 2011 UTC

5 Qt and POE are various supported event loops/environments. 5 Qt and POE are various supported event loops/environments.
6 6
7SYNOPSIS 7SYNOPSIS
8 use AnyEvent; 8 use AnyEvent;
9 9
10 # if you prefer function calls, look at the AE manpage for
11 # an alternative API.
12
10 # file descriptor readable 13 # file handle or descriptor readable
11 my $w = AnyEvent->io (fh => $fh, poll => "r", cb => sub { ... }); 14 my $w = AnyEvent->io (fh => $fh, poll => "r", cb => sub { ... });
12 15
13 # one-shot or repeating timers 16 # one-shot or repeating timers
14 my $w = AnyEvent->timer (after => $seconds, cb => sub { ... }); 17 my $w = AnyEvent->timer (after => $seconds, cb => sub { ... });
15 my $w = AnyEvent->timer (after => $seconds, interval => $seconds, cb => ... 18 my $w = AnyEvent->timer (after => $seconds, interval => $seconds, cb => ...);
16 19
17 print AnyEvent->now; # prints current event loop time 20 print AnyEvent->now; # prints current event loop time
18 print AnyEvent->time; # think Time::HiRes::time or simply CORE::time. 21 print AnyEvent->time; # think Time::HiRes::time or simply CORE::time.
19 22
20 # POSIX signal 23 # POSIX signal
39 This manpage is mainly a reference manual. If you are interested in a 42 This manpage is mainly a reference manual. If you are interested in a
40 tutorial or some gentle introduction, have a look at the AnyEvent::Intro 43 tutorial or some gentle introduction, have a look at the AnyEvent::Intro
41 manpage. 44 manpage.
42 45
43SUPPORT 46SUPPORT
47 An FAQ document is available as AnyEvent::FAQ.
48
44 There is a mailinglist for discussing all things AnyEvent, and an IRC 49 There also is a mailinglist for discussing all things AnyEvent, and an
45 channel, too. 50 IRC channel, too.
46 51
47 See the AnyEvent project page at the Schmorpforge Ta-Sa Software 52 See the AnyEvent project page at the Schmorpforge Ta-Sa Software
48 Repository, at <http://anyevent.schmorp.de>, for more info. 53 Repository, at <http://anyevent.schmorp.de>, for more info.
49 54
50WHY YOU SHOULD USE THIS MODULE (OR NOT) 55WHY YOU SHOULD USE THIS MODULE (OR NOT)
68 module users into the same thing by forcing them to use the same event 73 module users into the same thing by forcing them to use the same event
69 model you use. 74 model you use.
70 75
71 For modules like POE or IO::Async (which is a total misnomer as it is 76 For modules like POE or IO::Async (which is a total misnomer as it is
72 actually doing all I/O *synchronously*...), using them in your module is 77 actually doing all I/O *synchronously*...), using them in your module is
73 like joining a cult: After you joined, you are dependent on them and you 78 like joining a cult: After you join, you are dependent on them and you
74 cannot use anything else, as they are simply incompatible to everything 79 cannot use anything else, as they are simply incompatible to everything
75 that isn't them. What's worse, all the potential users of your module 80 that isn't them. What's worse, all the potential users of your module
76 are *also* forced to use the same event loop you use. 81 are *also* forced to use the same event loop you use.
77 82
78 AnyEvent is different: AnyEvent + POE works fine. AnyEvent + Glib works 83 AnyEvent is different: AnyEvent + POE works fine. AnyEvent + Glib works
79 fine. AnyEvent + Tk works fine etc. etc. but none of these work together 84 fine. AnyEvent + Tk works fine etc. etc. but none of these work together
80 with the rest: POE + IO::Async? No go. Tk + Event? No go. Again: if your 85 with the rest: POE + EV? No go. Tk + Event? No go. Again: if your module
81 module uses one of those, every user of your module has to use it, too. 86 uses one of those, every user of your module has to use it, too. But if
82 But if your module uses AnyEvent, it works transparently with all event 87 your module uses AnyEvent, it works transparently with all event models
83 models it supports (including stuff like IO::Async, as long as those use 88 it supports (including stuff like IO::Async, as long as those use one of
84 one of the supported event loops. It is trivial to add new event loops 89 the supported event loops. It is easy to add new event loops to
85 to AnyEvent, too, so it is future-proof). 90 AnyEvent, too, so it is future-proof).
86 91
87 In addition to being free of having to use *the one and only true event 92 In addition to being free of having to use *the one and only true event
88 model*, AnyEvent also is free of bloat and policy: with POE or similar 93 model*, AnyEvent also is free of bloat and policy: with POE or similar
89 modules, you get an enormous amount of code and strict rules you have to 94 modules, you get an enormous amount of code and strict rules you have to
90 follow. AnyEvent, on the other hand, is lean and up to the point, by 95 follow. AnyEvent, on the other hand, is lean and to the point, by only
91 only offering the functionality that is necessary, in as thin as a 96 offering the functionality that is necessary, in as thin as a wrapper as
92 wrapper as technically possible. 97 technically possible.
93 98
94 Of course, AnyEvent comes with a big (and fully optional!) toolbox of 99 Of course, AnyEvent comes with a big (and fully optional!) toolbox of
95 useful functionality, such as an asynchronous DNS resolver, 100% 100 useful functionality, such as an asynchronous DNS resolver, 100%
96 non-blocking connects (even with TLS/SSL, IPv6 and on broken platforms 101 non-blocking connects (even with TLS/SSL, IPv6 and on broken platforms
97 such as Windows) and lots of real-world knowledge and workarounds for 102 such as Windows) and lots of real-world knowledge and workarounds for
100 Now, if you *do want* lots of policy (this can arguably be somewhat 105 Now, if you *do want* lots of policy (this can arguably be somewhat
101 useful) and you want to force your users to use the one and only event 106 useful) and you want to force your users to use the one and only event
102 model, you should *not* use this module. 107 model, you should *not* use this module.
103 108
104DESCRIPTION 109DESCRIPTION
105 AnyEvent provides an identical interface to multiple event loops. This 110 AnyEvent provides a uniform interface to various event loops. This
106 allows module authors to utilise an event loop without forcing module 111 allows module authors to use event loop functionality without forcing
107 users to use the same event loop (as only a single event loop can 112 module users to use a specific event loop implementation (since more
108 coexist peacefully at any one time). 113 than one event loop cannot coexist peacefully).
109 114
110 The interface itself is vaguely similar, but not identical to the Event 115 The interface itself is vaguely similar, but not identical to the Event
111 module. 116 module.
112 117
113 During the first call of any watcher-creation method, the module tries 118 During the first call of any watcher-creation method, the module tries
114 to detect the currently loaded event loop by probing whether one of the 119 to detect the currently loaded event loop by probing whether one of the
115 following modules is already loaded: EV, Event, Glib, 120 following modules is already loaded: EV, AnyEvent::Loop, Event, Glib,
116 AnyEvent::Impl::Perl, Tk, Event::Lib, Qt, POE. The first one found is 121 Tk, Event::Lib, Qt, POE. The first one found is used. If none are
117 used. If none are found, the module tries to load these modules 122 detected, the module tries to load the first four modules in the order
118 (excluding Tk, Event::Lib, Qt and POE as the pure perl adaptor should 123 given; but note that if EV is not available, the pure-perl
119 always succeed) in the order given. The first one that can be 124 AnyEvent::Loop should always work, so the other two are not normally
120 successfully loaded will be used. If, after this, still none could be 125 tried.
121 found, AnyEvent will fall back to a pure-perl event loop, which is not
122 very efficient, but should work everywhere.
123 126
124 Because AnyEvent first checks for modules that are already loaded, 127 Because AnyEvent first checks for modules that are already loaded,
125 loading an event model explicitly before first using AnyEvent will 128 loading an event model explicitly before first using AnyEvent will
126 likely make that model the default. For example: 129 likely make that model the default. For example:
127 130
129 use AnyEvent; 132 use AnyEvent;
130 133
131 # .. AnyEvent will likely default to Tk 134 # .. AnyEvent will likely default to Tk
132 135
133 The *likely* means that, if any module loads another event model and 136 The *likely* means that, if any module loads another event model and
134 starts using it, all bets are off. Maybe you should tell their authors 137 starts using it, all bets are off - this case should be very rare
135 to use AnyEvent so their modules work together with others seamlessly... 138 though, as very few modules hardcode event loops without announcing this
139 very loudly.
136 140
137 The pure-perl implementation of AnyEvent is called 141 The pure-perl implementation of AnyEvent is called "AnyEvent::Loop".
138 "AnyEvent::Impl::Perl". Like other event modules you can load it 142 Like other event modules you can load it explicitly and enjoy the high
139 explicitly and enjoy the high availability of that event loop :) 143 availability of that event loop :)
140 144
141WATCHERS 145WATCHERS
142 AnyEvent has the central concept of a *watcher*, which is an object that 146 AnyEvent has the central concept of a *watcher*, which is an object that
143 stores relevant data for each kind of event you are waiting for, such as 147 stores relevant data for each kind of event you are waiting for, such as
144 the callback to call, the file handle to watch, etc. 148 the callback to call, the file handle to watch, etc.
148 callback when the event occurs (of course, only when the event model is 152 callback when the event occurs (of course, only when the event model is
149 in control). 153 in control).
150 154
151 Note that callbacks must not permanently change global variables 155 Note that callbacks must not permanently change global variables
152 potentially in use by the event loop (such as $_ or $[) and that 156 potentially in use by the event loop (such as $_ or $[) and that
153 callbacks must not "die". The former is good programming practise in 157 callbacks must not "die". The former is good programming practice in
154 Perl and the latter stems from the fact that exception handling differs 158 Perl and the latter stems from the fact that exception handling differs
155 widely between event loops. 159 widely between event loops.
156 160
157 To disable the watcher you have to destroy it (e.g. by setting the 161 To disable a watcher you have to destroy it (e.g. by setting the
158 variable you store it in to "undef" or otherwise deleting all references 162 variable you store it in to "undef" or otherwise deleting all references
159 to it). 163 to it).
160 164
161 All watchers are created by calling a method on the "AnyEvent" class. 165 All watchers are created by calling a method on the "AnyEvent" class.
162 166
163 Many watchers either are used with "recursion" (repeating timers for 167 Many watchers either are used with "recursion" (repeating timers for
164 example), or need to refer to their watcher object in other ways. 168 example), or need to refer to their watcher object in other ways.
165 169
166 An any way to achieve that is this pattern: 170 One way to achieve that is this pattern:
167 171
168 my $w; $w = AnyEvent->type (arg => value ..., cb => sub { 172 my $w; $w = AnyEvent->type (arg => value ..., cb => sub {
169 # you can use $w here, for example to undef it 173 # you can use $w here, for example to undef it
170 undef $w; 174 undef $w;
171 }); 175 });
202 206
203 The I/O watcher might use the underlying file descriptor or a copy of 207 The I/O watcher might use the underlying file descriptor or a copy of
204 it. You must not close a file handle as long as any watcher is active on 208 it. You must not close a file handle as long as any watcher is active on
205 the underlying file descriptor. 209 the underlying file descriptor.
206 210
207 Some event loops issue spurious readyness notifications, so you should 211 Some event loops issue spurious readiness notifications, so you should
208 always use non-blocking calls when reading/writing from/to your file 212 always use non-blocking calls when reading/writing from/to your file
209 handles. 213 handles.
210 214
211 Example: wait for readability of STDIN, then read a line and disable the 215 Example: wait for readability of STDIN, then read a line and disable the
212 watcher. 216 watcher.
235 239
236 Although the callback might get passed parameters, their value and 240 Although the callback might get passed parameters, their value and
237 presence is undefined and you cannot rely on them. Portable AnyEvent 241 presence is undefined and you cannot rely on them. Portable AnyEvent
238 callbacks cannot use arguments passed to time watcher callbacks. 242 callbacks cannot use arguments passed to time watcher callbacks.
239 243
240 The callback will normally be invoked once only. If you specify another 244 The callback will normally be invoked only once. If you specify another
241 parameter, "interval", as a strictly positive number (> 0), then the 245 parameter, "interval", as a strictly positive number (> 0), then the
242 callback will be invoked regularly at that interval (in fractional 246 callback will be invoked regularly at that interval (in fractional
243 seconds) after the first invocation. If "interval" is specified with a 247 seconds) after the first invocation. If "interval" is specified with a
244 false value, then it is treated as if it were missing. 248 false value, then it is treated as if it were not specified at all.
245 249
246 The callback will be rescheduled before invoking the callback, but no 250 The callback will be rescheduled before invoking the callback, but no
247 attempt is done to avoid timer drift in most backends, so the interval 251 attempt is made to avoid timer drift in most backends, so the interval
248 is only approximate. 252 is only approximate.
249 253
250 Example: fire an event after 7.7 seconds. 254 Example: fire an event after 7.7 seconds.
251 255
252 my $w = AnyEvent->timer (after => 7.7, cb => sub { 256 my $w = AnyEvent->timer (after => 7.7, cb => sub {
269 273
270 While most event loops expect timers to specified in a relative way, 274 While most event loops expect timers to specified in a relative way,
271 they use absolute time internally. This makes a difference when your 275 they use absolute time internally. This makes a difference when your
272 clock "jumps", for example, when ntp decides to set your clock backwards 276 clock "jumps", for example, when ntp decides to set your clock backwards
273 from the wrong date of 2014-01-01 to 2008-01-01, a watcher that is 277 from the wrong date of 2014-01-01 to 2008-01-01, a watcher that is
274 supposed to fire "after" a second might actually take six years to 278 supposed to fire "after a second" might actually take six years to
275 finally fire. 279 finally fire.
276 280
277 AnyEvent cannot compensate for this. The only event loop that is 281 AnyEvent cannot compensate for this. The only event loop that is
278 conscious about these issues is EV, which offers both relative 282 conscious of these issues is EV, which offers both relative (ev_timer,
279 (ev_timer, based on true relative time) and absolute (ev_periodic, based 283 based on true relative time) and absolute (ev_periodic, based on
280 on wallclock time) timers. 284 wallclock time) timers.
281 285
282 AnyEvent always prefers relative timers, if available, matching the 286 AnyEvent always prefers relative timers, if available, matching the
283 AnyEvent API. 287 AnyEvent API.
284 288
285 AnyEvent has two additional methods that return the "current time": 289 AnyEvent has two additional methods that return the "current time":
304 *In almost all cases (in all cases if you don't care), this is the 308 *In almost all cases (in all cases if you don't care), this is the
305 function to call when you want to know the current time.* 309 function to call when you want to know the current time.*
306 310
307 This function is also often faster then "AnyEvent->time", and thus 311 This function is also often faster then "AnyEvent->time", and thus
308 the preferred method if you want some timestamp (for example, 312 the preferred method if you want some timestamp (for example,
309 AnyEvent::Handle uses this to update it's activity timeouts). 313 AnyEvent::Handle uses this to update its activity timeouts).
310 314
311 The rest of this section is only of relevance if you try to be very 315 The rest of this section is only of relevance if you try to be very
312 exact with your timing, you can skip it without bad conscience. 316 exact with your timing; you can skip it without a bad conscience.
313 317
314 For a practical example of when these times differ, consider 318 For a practical example of when these times differ, consider
315 Event::Lib and EV and the following set-up: 319 Event::Lib and EV and the following set-up:
316 320
317 The event loop is running and has just invoked one of your callback 321 The event loop is running and has just invoked one of your callbacks
318 at time=500 (assume no other callbacks delay processing). In your 322 at time=500 (assume no other callbacks delay processing). In your
319 callback, you wait a second by executing "sleep 1" (blocking the 323 callback, you wait a second by executing "sleep 1" (blocking the
320 process for a second) and then (at time=501) you create a relative 324 process for a second) and then (at time=501) you create a relative
321 timer that fires after three seconds. 325 timer that fires after three seconds.
322 326
343 can get whatever behaviour you want with any event loop, by taking 347 can get whatever behaviour you want with any event loop, by taking
344 the difference between "AnyEvent->time" and "AnyEvent->now" into 348 the difference between "AnyEvent->time" and "AnyEvent->now" into
345 account. 349 account.
346 350
347 AnyEvent->now_update 351 AnyEvent->now_update
348 Some event loops (such as EV or AnyEvent::Impl::Perl) cache the 352 Some event loops (such as EV or AnyEvent::Loop) cache the current
349 current time for each loop iteration (see the discussion of 353 time for each loop iteration (see the discussion of AnyEvent->now,
350 AnyEvent->now, above). 354 above).
351 355
352 When a callback runs for a long time (or when the process sleeps), 356 When a callback runs for a long time (or when the process sleeps),
353 then this "current" time will differ substantially from the real 357 then this "current" time will differ substantially from the real
354 time, which might affect timers and time-outs. 358 time, which might affect timers and time-outs.
355 359
356 When this is the case, you can call this method, which will update 360 When this is the case, you can call this method, which will update
357 the event loop's idea of "current time". 361 the event loop's idea of "current time".
362
363 A typical example would be a script in a web server (e.g.
364 "mod_perl") - when mod_perl executes the script, then the event loop
365 will have the wrong idea about the "current time" (being potentially
366 far in the past, when the script ran the last time). In that case
367 you should arrange a call to "AnyEvent->now_update" each time the
368 web server process wakes up again (e.g. at the start of your script,
369 or in a handler).
358 370
359 Note that updating the time *might* cause some events to be handled. 371 Note that updating the time *might* cause some events to be handled.
360 372
361 SIGNAL WATCHERS 373 SIGNAL WATCHERS
362 $w = AnyEvent->signal (signal => <uppercase_signal_name>, cb => <callback>); 374 $w = AnyEvent->signal (signal => <uppercase_signal_name>, cb => <callback>);
384 396
385 Example: exit on SIGINT 397 Example: exit on SIGINT
386 398
387 my $w = AnyEvent->signal (signal => "INT", cb => sub { exit 1 }); 399 my $w = AnyEvent->signal (signal => "INT", cb => sub { exit 1 });
388 400
401 Restart Behaviour
402 While restart behaviour is up to the event loop implementation, most
403 will not restart syscalls (that includes Async::Interrupt and AnyEvent's
404 pure perl implementation).
405
406 Safe/Unsafe Signals
407 Perl signals can be either "safe" (synchronous to opcode handling) or
408 "unsafe" (asynchronous) - the former might get delayed indefinitely, the
409 latter might corrupt your memory.
410
411 AnyEvent signal handlers are, in addition, synchronous to the event
412 loop, i.e. they will not interrupt your running perl program but will
413 only be called as part of the normal event handling (just like timer,
414 I/O etc. callbacks, too).
415
389 Signal Races, Delays and Workarounds 416 Signal Races, Delays and Workarounds
390 Many event loops (e.g. Glib, Tk, Qt, IO::Async) do not support attaching 417 Many event loops (e.g. Glib, Tk, Qt, IO::Async) do not support attaching
391 callbacks to signals in a generic way, which is a pity, as you cannot do 418 callbacks to signals in a generic way, which is a pity, as you cannot do
392 race-free signal handling in perl, requiring C libraries for this. 419 race-free signal handling in perl, requiring C libraries for this.
393 AnyEvent will try to do it's best, which means in some cases, signals 420 AnyEvent will try to do its best, which means in some cases, signals
394 will be delayed. The maximum time a signal might be delayed is specified 421 will be delayed. The maximum time a signal might be delayed is specified
395 in $AnyEvent::MAX_SIGNAL_LATENCY (default: 10 seconds). This variable 422 in $AnyEvent::MAX_SIGNAL_LATENCY (default: 10 seconds). This variable
396 can be changed only before the first signal watcher is created, and 423 can be changed only before the first signal watcher is created, and
397 should be left alone otherwise. This variable determines how often 424 should be left alone otherwise. This variable determines how often
398 AnyEvent polls for signals (in case a wake-up was missed). Higher values 425 AnyEvent polls for signals (in case a wake-up was missed). Higher values
400 saving. 427 saving.
401 428
402 All these problems can be avoided by installing the optional 429 All these problems can be avoided by installing the optional
403 Async::Interrupt module, which works with most event loops. It will not 430 Async::Interrupt module, which works with most event loops. It will not
404 work with inherently broken event loops such as Event or Event::Lib (and 431 work with inherently broken event loops such as Event or Event::Lib (and
405 not with POE currently, as POE does it's own workaround with one-second 432 not with POE currently, as POE does its own workaround with one-second
406 latency). For those, you just have to suffer the delays. 433 latency). For those, you just have to suffer the delays.
407 434
408 CHILD PROCESS WATCHERS 435 CHILD PROCESS WATCHERS
409 $w = AnyEvent->child (pid => <process id>, cb => <callback>); 436 $w = AnyEvent->child (pid => <process id>, cb => <callback>);
410 437
411 You can also watch on a child process exit and catch its exit status. 438 You can also watch for a child process exit and catch its exit status.
412 439
413 The child process is specified by the "pid" argument (one some backends, 440 The child process is specified by the "pid" argument (on some backends,
414 using 0 watches for any child process exit, on others this will croak). 441 using 0 watches for any child process exit, on others this will croak).
415 The watcher will be triggered only when the child process has finished 442 The watcher will be triggered only when the child process has finished
416 and an exit status is available, not on any trace events 443 and an exit status is available, not on any trace events
417 (stopped/continued). 444 (stopped/continued).
418 445
439 This means you cannot create a child watcher as the very first thing in 466 This means you cannot create a child watcher as the very first thing in
440 an AnyEvent program, you *have* to create at least one watcher before 467 an AnyEvent program, you *have* to create at least one watcher before
441 you "fork" the child (alternatively, you can call "AnyEvent::detect"). 468 you "fork" the child (alternatively, you can call "AnyEvent::detect").
442 469
443 As most event loops do not support waiting for child events, they will 470 As most event loops do not support waiting for child events, they will
444 be emulated by AnyEvent in most cases, in which the latency and race 471 be emulated by AnyEvent in most cases, in which case the latency and
445 problems mentioned in the description of signal watchers apply. 472 race problems mentioned in the description of signal watchers apply.
446 473
447 Example: fork a process and wait for it 474 Example: fork a process and wait for it
448 475
449 my $done = AnyEvent->condvar; 476 my $done = AnyEvent->condvar;
450 477
463 $done->recv; 490 $done->recv;
464 491
465 IDLE WATCHERS 492 IDLE WATCHERS
466 $w = AnyEvent->idle (cb => <callback>); 493 $w = AnyEvent->idle (cb => <callback>);
467 494
468 Sometimes there is a need to do something, but it is not so important to 495 This will repeatedly invoke the callback after the process becomes idle,
469 do it instantly, but only when there is nothing better to do. This 496 until either the watcher is destroyed or new events have been detected.
470 "nothing better to do" is usually defined to be "no other events need
471 attention by the event loop".
472 497
473 Idle watchers ideally get invoked when the event loop has nothing better 498 Idle watchers are useful when there is a need to do something, but it is
474 to do, just before it would block the process to wait for new events. 499 not so important (or wise) to do it instantly. The callback will be
475 Instead of blocking, the idle watcher is invoked. 500 invoked only when there is "nothing better to do", which is usually
501 defined as "all outstanding events have been handled and no new events
502 have been detected". That means that idle watchers ideally get invoked
503 when the event loop has just polled for new events but none have been
504 detected. Instead of blocking to wait for more events, the idle watchers
505 will be invoked.
476 506
477 Most event loops unfortunately do not really support idle watchers (only 507 Unfortunately, most event loops do not really support idle watchers
478 EV, Event and Glib do it in a usable fashion) - for the rest, AnyEvent 508 (only EV, Event and Glib do it in a usable fashion) - for the rest,
479 will simply call the callback "from time to time". 509 AnyEvent will simply call the callback "from time to time".
480 510
481 Example: read lines from STDIN, but only process them when the program 511 Example: read lines from STDIN, but only process them when the program
482 is otherwise idle: 512 is otherwise idle:
483 513
484 my @lines; # read data 514 my @lines; # read data
510 540
511 AnyEvent is slightly different: it expects somebody else to run the 541 AnyEvent is slightly different: it expects somebody else to run the
512 event loop and will only block when necessary (usually when told by the 542 event loop and will only block when necessary (usually when told by the
513 user). 543 user).
514 544
515 The instrument to do that is called a "condition variable", so called 545 The tool to do that is called a "condition variable", so called because
516 because they represent a condition that must become true. 546 they represent a condition that must become true.
517 547
518 Now is probably a good time to look at the examples further below. 548 Now is probably a good time to look at the examples further below.
519 549
520 Condition variables can be created by calling the "AnyEvent->condvar" 550 Condition variables can be created by calling the "AnyEvent->condvar"
521 method, usually without arguments. The only argument pair allowed is 551 method, usually without arguments. The only argument pair allowed is
526 After creation, the condition variable is "false" until it becomes 556 After creation, the condition variable is "false" until it becomes
527 "true" by calling the "send" method (or calling the condition variable 557 "true" by calling the "send" method (or calling the condition variable
528 as if it were a callback, read about the caveats in the description for 558 as if it were a callback, read about the caveats in the description for
529 the "->send" method). 559 the "->send" method).
530 560
531 Condition variables are similar to callbacks, except that you can 561 Since condition variables are the most complex part of the AnyEvent API,
532 optionally wait for them. They can also be called merge points - points 562 here are some different mental models of what they are - pick the ones
533 in time where multiple outstanding events have been processed. And yet 563 you can connect to:
534 another way to call them is transactions - each condition variable can 564
535 be used to represent a transaction, which finishes at some point and 565 * Condition variables are like callbacks - you can call them (and pass
536 delivers a result. And yet some people know them as "futures" - a 566 them instead of callbacks). Unlike callbacks however, you can also
537 promise to compute/deliver something that you can wait for. 567 wait for them to be called.
568
569 * Condition variables are signals - one side can emit or send them,
570 the other side can wait for them, or install a handler that is
571 called when the signal fires.
572
573 * Condition variables are like "Merge Points" - points in your program
574 where you merge multiple independent results/control flows into one.
575
576 * Condition variables represent a transaction - functions that start
577 some kind of transaction can return them, leaving the caller the
578 choice between waiting in a blocking fashion, or setting a callback.
579
580 * Condition variables represent future values, or promises to deliver
581 some result, long before the result is available.
538 582
539 Condition variables are very useful to signal that something has 583 Condition variables are very useful to signal that something has
540 finished, for example, if you write a module that does asynchronous http 584 finished, for example, if you write a module that does asynchronous http
541 requests, then a condition variable would be the ideal candidate to 585 requests, then a condition variable would be the ideal candidate to
542 signal the availability of results. The user can either act when the 586 signal the availability of results. The user can either act when the
555 599
556 Condition variables are represented by hash refs in perl, and the keys 600 Condition variables are represented by hash refs in perl, and the keys
557 used by AnyEvent itself are all named "_ae_XXX" to make subclassing easy 601 used by AnyEvent itself are all named "_ae_XXX" to make subclassing easy
558 (it is often useful to build your own transaction class on top of 602 (it is often useful to build your own transaction class on top of
559 AnyEvent). To subclass, use "AnyEvent::CondVar" as base class and call 603 AnyEvent). To subclass, use "AnyEvent::CondVar" as base class and call
560 it's "new" method in your own "new" method. 604 its "new" method in your own "new" method.
561 605
562 There are two "sides" to a condition variable - the "producer side" 606 There are two "sides" to a condition variable - the "producer side"
563 which eventually calls "-> send", and the "consumer side", which waits 607 which eventually calls "-> send", and the "consumer side", which waits
564 for the send to occur. 608 for the send to occur.
565 609
566 Example: wait for a timer. 610 Example: wait for a timer.
567 611
568 # wait till the result is ready 612 # condition: "wait till the timer is fired"
569 my $result_ready = AnyEvent->condvar; 613 my $timer_fired = AnyEvent->condvar;
570 614
571 # do something such as adding a timer 615 # create the timer - we could wait for, say
572 # or socket watcher the calls $result_ready->send 616 # a handle becomign ready, or even an
573 # when the "result" is ready. 617 # AnyEvent::HTTP request to finish, but
574 # in this case, we simply use a timer: 618 # in this case, we simply use a timer:
575 my $w = AnyEvent->timer ( 619 my $w = AnyEvent->timer (
576 after => 1, 620 after => 1,
577 cb => sub { $result_ready->send }, 621 cb => sub { $timer_fired->send },
578 ); 622 );
579 623
580 # this "blocks" (while handling events) till the callback 624 # this "blocks" (while handling events) till the callback
581 # calls ->send 625 # calls ->send
582 $result_ready->recv; 626 $timer_fired->recv;
583 627
584 Example: wait for a timer, but take advantage of the fact that condition 628 Example: wait for a timer, but take advantage of the fact that condition
585 variables are also callable directly. 629 variables are also callable directly.
586 630
587 my $done = AnyEvent->condvar; 631 my $done = AnyEvent->condvar;
625 Condition variables are overloaded so one can call them directly (as 669 Condition variables are overloaded so one can call them directly (as
626 if they were a code reference). Calling them directly is the same as 670 if they were a code reference). Calling them directly is the same as
627 calling "send". 671 calling "send".
628 672
629 $cv->croak ($error) 673 $cv->croak ($error)
630 Similar to send, but causes all call's to "->recv" to invoke 674 Similar to send, but causes all calls to "->recv" to invoke
631 "Carp::croak" with the given error message/object/scalar. 675 "Carp::croak" with the given error message/object/scalar.
632 676
633 This can be used to signal any errors to the condition variable 677 This can be used to signal any errors to the condition variable
634 user/consumer. Doing it this way instead of calling "croak" directly 678 user/consumer. Doing it this way instead of calling "croak" directly
635 delays the error detetcion, but has the overwhelmign advantage that 679 delays the error detection, but has the overwhelming advantage that
636 it diagnoses the error at the place where the result is expected, 680 it diagnoses the error at the place where the result is expected,
637 and not deep in some event clalback without connection to the actual 681 and not deep in some event callback with no connection to the actual
638 code causing the problem. 682 code causing the problem.
639 683
640 $cv->begin ([group callback]) 684 $cv->begin ([group callback])
641 $cv->end 685 $cv->end
642 These two methods can be used to combine many transactions/events 686 These two methods can be used to combine many transactions/events
679 there is one call to "begin", so the condvar waits for all calls to 723 there is one call to "begin", so the condvar waits for all calls to
680 "end" before sending. 724 "end" before sending.
681 725
682 The ping example mentioned above is slightly more complicated, as 726 The ping example mentioned above is slightly more complicated, as
683 the there are results to be passwd back, and the number of tasks 727 the there are results to be passwd back, and the number of tasks
684 that are begung can potentially be zero: 728 that are begun can potentially be zero:
685 729
686 my $cv = AnyEvent->condvar; 730 my $cv = AnyEvent->condvar;
687 731
688 my %result; 732 my %result;
689 $cv->begin (sub { shift->send (\%result) }); 733 $cv->begin (sub { shift->send (\%result) });
710 callback to be called once the counter reaches 0, and second, it 754 callback to be called once the counter reaches 0, and second, it
711 ensures that "send" is called even when "no" hosts are being pinged 755 ensures that "send" is called even when "no" hosts are being pinged
712 (the loop doesn't execute once). 756 (the loop doesn't execute once).
713 757
714 This is the general pattern when you "fan out" into multiple (but 758 This is the general pattern when you "fan out" into multiple (but
715 potentially none) subrequests: use an outer "begin"/"end" pair to 759 potentially zero) subrequests: use an outer "begin"/"end" pair to
716 set the callback and ensure "end" is called at least once, and then, 760 set the callback and ensure "end" is called at least once, and then,
717 for each subrequest you start, call "begin" and for each subrequest 761 for each subrequest you start, call "begin" and for each subrequest
718 you finish, call "end". 762 you finish, call "end".
719 763
720 METHODS FOR CONSUMERS 764 METHODS FOR CONSUMERS
721 These methods should only be used by the consuming side, i.e. the code 765 These methods should only be used by the consuming side, i.e. the code
722 awaits the condition. 766 awaits the condition.
723 767
724 $cv->recv 768 $cv->recv
725 Wait (blocking if necessary) until the "->send" or "->croak" methods 769 Wait (blocking if necessary) until the "->send" or "->croak" methods
726 have been called on c<$cv>, while servicing other watchers normally. 770 have been called on $cv, while servicing other watchers normally.
727 771
728 You can only wait once on a condition - additional calls are valid 772 You can only wait once on a condition - additional calls are valid
729 but will return immediately. 773 but will return immediately.
730 774
731 If an error condition has been set by calling "->croak", then this 775 If an error condition has been set by calling "->croak", then this
748 example, by coupling condition variables with some kind of request 792 example, by coupling condition variables with some kind of request
749 results and supporting callbacks so the caller knows that getting 793 results and supporting callbacks so the caller knows that getting
750 the result will not block, while still supporting blocking waits if 794 the result will not block, while still supporting blocking waits if
751 the caller so desires). 795 the caller so desires).
752 796
753 You can ensure that "-recv" never blocks by setting a callback and 797 You can ensure that "->recv" never blocks by setting a callback and
754 only calling "->recv" from within that callback (or at a later 798 only calling "->recv" from within that callback (or at a later
755 time). This will work even when the event loop does not support 799 time). This will work even when the event loop does not support
756 blocking waits otherwise. 800 blocking waits otherwise.
757 801
758 $bool = $cv->ready 802 $bool = $cv->ready
761 805
762 $cb = $cv->cb ($cb->($cv)) 806 $cb = $cv->cb ($cb->($cv))
763 This is a mutator function that returns the callback set and 807 This is a mutator function that returns the callback set and
764 optionally replaces it before doing so. 808 optionally replaces it before doing so.
765 809
766 The callback will be called when the condition becomes (or already 810 The callback will be called when the condition becomes "true", i.e.
767 was) "true", i.e. when "send" or "croak" are called (or were 811 when "send" or "croak" are called, with the only argument being the
768 called), with the only argument being the condition variable itself. 812 condition variable itself. If the condition is already true, the
769 Calling "recv" inside the callback or at any later time is 813 callback is called immediately when it is set. Calling "recv" inside
770 guaranteed not to block. 814 the callback or at any later time is guaranteed not to block.
771 815
772SUPPORTED EVENT LOOPS/BACKENDS 816SUPPORTED EVENT LOOPS/BACKENDS
773 The available backend classes are (every class has its own manpage): 817 The available backend classes are (every class has its own manpage):
774 818
775 Backends that are autoprobed when no other event loop can be found. 819 Backends that are autoprobed when no other event loop can be found.
777 use. If EV is not installed, then AnyEvent will fall back to its own 821 use. If EV is not installed, then AnyEvent will fall back to its own
778 pure-perl implementation, which is available everywhere as it comes 822 pure-perl implementation, which is available everywhere as it comes
779 with AnyEvent itself. 823 with AnyEvent itself.
780 824
781 AnyEvent::Impl::EV based on EV (interface to libev, best choice). 825 AnyEvent::Impl::EV based on EV (interface to libev, best choice).
782 AnyEvent::Impl::Perl pure-perl implementation, fast and portable. 826 AnyEvent::Impl::Perl pure-perl AnyEvent::Loop, fast and portable.
783 827
784 Backends that are transparently being picked up when they are used. 828 Backends that are transparently being picked up when they are used.
785 These will be used when they are currently loaded when the first 829 These will be used if they are already loaded when the first watcher
786 watcher is created, in which case it is assumed that the application 830 is created, in which case it is assumed that the application is
787 is using them. This means that AnyEvent will automatically pick the 831 using them. This means that AnyEvent will automatically pick the
788 right backend when the main program loads an event module before 832 right backend when the main program loads an event module before
789 anything starts to create watchers. Nothing special needs to be done 833 anything starts to create watchers. Nothing special needs to be done
790 by the main program. 834 by the main program.
791 835
792 AnyEvent::Impl::Event based on Event, very stable, few glitches. 836 AnyEvent::Impl::Event based on Event, very stable, few glitches.
793 AnyEvent::Impl::Glib based on Glib, slow but very stable. 837 AnyEvent::Impl::Glib based on Glib, slow but very stable.
794 AnyEvent::Impl::Tk based on Tk, very broken. 838 AnyEvent::Impl::Tk based on Tk, very broken.
795 AnyEvent::Impl::EventLib based on Event::Lib, leaks memory and worse. 839 AnyEvent::Impl::EventLib based on Event::Lib, leaks memory and worse.
796 AnyEvent::Impl::POE based on POE, very slow, some limitations. 840 AnyEvent::Impl::POE based on POE, very slow, some limitations.
797 AnyEvent::Impl::Irssi used when running within irssi. 841 AnyEvent::Impl::Irssi used when running within irssi.
842 AnyEvent::Impl::IOAsync based on IO::Async.
843 AnyEvent::Impl::Cocoa based on Cocoa::EventLoop.
844 AnyEvent::Impl::FLTK2 based on FLTK (fltk 2 binding).
798 845
799 Backends with special needs. 846 Backends with special needs.
800 Qt requires the Qt::Application to be instantiated first, but will 847 Qt requires the Qt::Application to be instantiated first, but will
801 otherwise be picked up automatically. As long as the main program 848 otherwise be picked up automatically. As long as the main program
802 instantiates the application before any AnyEvent watchers are 849 instantiates the application before any AnyEvent watchers are
803 created, everything should just work. 850 created, everything should just work.
804 851
805 AnyEvent::Impl::Qt based on Qt. 852 AnyEvent::Impl::Qt based on Qt.
806 853
807 Support for IO::Async can only be partial, as it is too broken and
808 architecturally limited to even support the AnyEvent API. It also is
809 the only event loop that needs the loop to be set explicitly, so it
810 can only be used by a main program knowing about AnyEvent. See
811 AnyEvent::Impl::Async for the gory details.
812
813 AnyEvent::Impl::IOAsync based on IO::Async, cannot be autoprobed.
814
815 Event loops that are indirectly supported via other backends. 854 Event loops that are indirectly supported via other backends.
816 Some event loops can be supported via other modules: 855 Some event loops can be supported via other modules:
817 856
818 There is no direct support for WxWidgets (Wx) or Prima. 857 There is no direct support for WxWidgets (Wx) or Prima.
819 858
837 Contains "undef" until the first watcher is being created, before 876 Contains "undef" until the first watcher is being created, before
838 the backend has been autodetected. 877 the backend has been autodetected.
839 878
840 Afterwards it contains the event model that is being used, which is 879 Afterwards it contains the event model that is being used, which is
841 the name of the Perl class implementing the model. This class is 880 the name of the Perl class implementing the model. This class is
842 usually one of the "AnyEvent::Impl:xxx" modules, but can be any 881 usually one of the "AnyEvent::Impl::xxx" modules, but can be any
843 other class in the case AnyEvent has been extended at runtime (e.g. 882 other class in the case AnyEvent has been extended at runtime (e.g.
844 in *rxvt-unicode* it will be "urxvt::anyevent"). 883 in *rxvt-unicode* it will be "urxvt::anyevent").
845 884
846 AnyEvent::detect 885 AnyEvent::detect
847 Returns $AnyEvent::MODEL, forcing autodetection of the event model 886 Returns $AnyEvent::MODEL, forcing autodetection of the event model
848 if necessary. You should only call this function right before you 887 if necessary. You should only call this function right before you
849 would have created an AnyEvent watcher anyway, that is, as late as 888 would have created an AnyEvent watcher anyway, that is, as late as
850 possible at runtime, and not e.g. while initialising of your module. 889 possible at runtime, and not e.g. during initialisation of your
890 module.
891
892 The effect of calling this function is as if a watcher had been
893 created (specifically, actions that happen "when the first watcher
894 is created" happen when calling detetc as well).
851 895
852 If you need to do some initialisation before AnyEvent watchers are 896 If you need to do some initialisation before AnyEvent watchers are
853 created, use "post_detect". 897 created, use "post_detect".
854 898
855 $guard = AnyEvent::post_detect { BLOCK } 899 $guard = AnyEvent::post_detect { BLOCK }
856 Arranges for the code block to be executed as soon as the event 900 Arranges for the code block to be executed as soon as the event
857 model is autodetected (or immediately if this has already happened). 901 model is autodetected (or immediately if that has already happened).
858 902
859 The block will be executed *after* the actual backend has been 903 The block will be executed *after* the actual backend has been
860 detected ($AnyEvent::MODEL is set), but *before* any watchers have 904 detected ($AnyEvent::MODEL is set), but *before* any watchers have
861 been created, so it is possible to e.g. patch @AnyEvent::ISA or do 905 been created, so it is possible to e.g. patch @AnyEvent::ISA or do
862 other initialisations - see the sources of AnyEvent::Strict or 906 other initialisations - see the sources of AnyEvent::Strict or
871 object that automatically removes the callback again when it is 915 object that automatically removes the callback again when it is
872 destroyed (or "undef" when the hook was immediately executed). See 916 destroyed (or "undef" when the hook was immediately executed). See
873 AnyEvent::AIO for a case where this is useful. 917 AnyEvent::AIO for a case where this is useful.
874 918
875 Example: Create a watcher for the IO::AIO module and store it in 919 Example: Create a watcher for the IO::AIO module and store it in
876 $WATCHER. Only do so after the event loop is initialised, though. 920 $WATCHER, but do so only do so after the event loop is initialised.
877 921
878 our WATCHER; 922 our WATCHER;
879 923
880 my $guard = AnyEvent::post_detect { 924 my $guard = AnyEvent::post_detect {
881 $WATCHER = AnyEvent->io (fh => IO::AIO::poll_fileno, poll => 'r', cb => \&IO::AIO::poll_cb); 925 $WATCHER = AnyEvent->io (fh => IO::AIO::poll_fileno, poll => 'r', cb => \&IO::AIO::poll_cb);
888 932
889 $WATCHER ||= $guard; 933 $WATCHER ||= $guard;
890 934
891 @AnyEvent::post_detect 935 @AnyEvent::post_detect
892 If there are any code references in this array (you can "push" to it 936 If there are any code references in this array (you can "push" to it
893 before or after loading AnyEvent), then they will called directly 937 before or after loading AnyEvent), then they will be called directly
894 after the event loop has been chosen. 938 after the event loop has been chosen.
895 939
896 You should check $AnyEvent::MODEL before adding to this array, 940 You should check $AnyEvent::MODEL before adding to this array,
897 though: if it is defined then the event loop has already been 941 though: if it is defined then the event loop has already been
898 detected, and the array will be ignored. 942 detected, and the array will be ignored.
899 943
900 Best use "AnyEvent::post_detect { BLOCK }" when your application 944 Best use "AnyEvent::post_detect { BLOCK }" when your application
901 allows it,as it takes care of these details. 945 allows it, as it takes care of these details.
902 946
903 This variable is mainly useful for modules that can do something 947 This variable is mainly useful for modules that can do something
904 useful when AnyEvent is used and thus want to know when it is 948 useful when AnyEvent is used and thus want to know when it is
905 initialised, but do not need to even load it by default. This array 949 initialised, but do not need to even load it by default. This array
906 provides the means to hook into AnyEvent passively, without loading 950 provides the means to hook into AnyEvent passively, without loading
907 it. 951 it.
908 952
953 Example: To load Coro::AnyEvent whenever Coro and AnyEvent are used
954 together, you could put this into Coro (this is the actual code used
955 by Coro to accomplish this):
956
957 if (defined $AnyEvent::MODEL) {
958 # AnyEvent already initialised, so load Coro::AnyEvent
959 require Coro::AnyEvent;
960 } else {
961 # AnyEvent not yet initialised, so make sure to load Coro::AnyEvent
962 # as soon as it is
963 push @AnyEvent::post_detect, sub { require Coro::AnyEvent };
964 }
965
966 AnyEvent::postpone { BLOCK }
967 Arranges for the block to be executed as soon as possible, but not
968 before the call itself returns. In practise, the block will be
969 executed just before the event loop polls for new events, or shortly
970 afterwards.
971
972 This function never returns anything (to make the "return postpone {
973 ... }" idiom more useful.
974
975 To understand the usefulness of this function, consider a function
976 that asynchronously does something for you and returns some
977 transaction object or guard to let you cancel the operation. For
978 example, "AnyEvent::Socket::tcp_connect":
979
980 # start a conenction attempt unless one is active
981 $self->{connect_guard} ||= AnyEvent::Socket::tcp_connect "www.example.net", 80, sub {
982 delete $self->{connect_guard};
983 ...
984 };
985
986 Imagine that this function could instantly call the callback, for
987 example, because it detects an obvious error such as a negative port
988 number. Invoking the callback before the function returns causes
989 problems however: the callback will be called and will try to delete
990 the guard object. But since the function hasn't returned yet, there
991 is nothing to delete. When the function eventually returns it will
992 assign the guard object to "$self->{connect_guard}", where it will
993 likely never be deleted, so the program thinks it is still trying to
994 connect.
995
996 This is where "AnyEvent::postpone" should be used. Instead of
997 calling the callback directly on error:
998
999 $cb->(undef), return # signal error to callback, BAD!
1000 if $some_error_condition;
1001
1002 It should use "postpone":
1003
1004 AnyEvent::postpone { $cb->(undef) }, return # signal error to callback, later
1005 if $some_error_condition;
1006
909WHAT TO DO IN A MODULE 1007WHAT TO DO IN A MODULE
910 As a module author, you should "use AnyEvent" and call AnyEvent methods 1008 As a module author, you should "use AnyEvent" and call AnyEvent methods
911 freely, but you should not load a specific event module or rely on it. 1009 freely, but you should not load a specific event module or rely on it.
912 1010
913 Be careful when you create watchers in the module body - AnyEvent will 1011 Be careful when you create watchers in the module body - AnyEvent will
920 stall the whole program, and the whole point of using events is to stay 1018 stall the whole program, and the whole point of using events is to stay
921 interactive. 1019 interactive.
922 1020
923 It is fine, however, to call "->recv" when the user of your module 1021 It is fine, however, to call "->recv" when the user of your module
924 requests it (i.e. if you create a http request object ad have a method 1022 requests it (i.e. if you create a http request object ad have a method
925 called "results" that returns the results, it should call "->recv" 1023 called "results" that returns the results, it may call "->recv" freely,
926 freely, as the user of your module knows what she is doing. always). 1024 as the user of your module knows what she is doing. Always).
927 1025
928WHAT TO DO IN THE MAIN PROGRAM 1026WHAT TO DO IN THE MAIN PROGRAM
929 There will always be a single main program - the only place that should 1027 There will always be a single main program - the only place that should
930 dictate which event model to use. 1028 dictate which event model to use.
931 1029
932 If it doesn't care, it can just "use AnyEvent" and use it itself, or not 1030 If the program is not event-based, it need not do anything special, even
933 do anything special (it does not need to be event-based) and let 1031 when it depends on a module that uses an AnyEvent. If the program itself
934 AnyEvent decide which implementation to chose if some module relies on 1032 uses AnyEvent, but does not care which event loop is used, all it needs
935 it. 1033 to do is "use AnyEvent". In either case, AnyEvent will choose the best
1034 available loop implementation.
936 1035
937 If the main program relies on a specific event model - for example, in 1036 If the main program relies on a specific event model - for example, in
938 Gtk2 programs you have to rely on the Glib module - you should load the 1037 Gtk2 programs you have to rely on the Glib module - you should load the
939 event module before loading AnyEvent or any module that uses it: 1038 event module before loading AnyEvent or any module that uses it:
940 generally speaking, you should load it as early as possible. The reason 1039 generally speaking, you should load it as early as possible. The reason
941 is that modules might create watchers when they are loaded, and AnyEvent 1040 is that modules might create watchers when they are loaded, and AnyEvent
942 will decide on the event model to use as soon as it creates watchers, 1041 will decide on the event model to use as soon as it creates watchers,
943 and it might chose the wrong one unless you load the correct one 1042 and it might choose the wrong one unless you load the correct one
944 yourself. 1043 yourself.
945 1044
946 You can chose to use a pure-perl implementation by loading the 1045 You can chose to use a pure-perl implementation by loading the
947 "AnyEvent::Impl::Perl" module, which gives you similar behaviour 1046 "AnyEvent::Loop" module, which gives you similar behaviour everywhere,
948 everywhere, but letting AnyEvent chose the model is generally better. 1047 but letting AnyEvent chose the model is generally better.
949 1048
950 MAINLOOP EMULATION 1049 MAINLOOP EMULATION
951 Sometimes (often for short test scripts, or even standalone programs who 1050 Sometimes (often for short test scripts, or even standalone programs who
952 only want to use AnyEvent), you do not want to run a specific event 1051 only want to use AnyEvent), you do not want to run a specific event
953 loop. 1052 loop.
965 1064
966OTHER MODULES 1065OTHER MODULES
967 The following is a non-exhaustive list of additional modules that use 1066 The following is a non-exhaustive list of additional modules that use
968 AnyEvent as a client and can therefore be mixed easily with other 1067 AnyEvent as a client and can therefore be mixed easily with other
969 AnyEvent modules and other event loops in the same program. Some of the 1068 AnyEvent modules and other event loops in the same program. Some of the
970 modules come with AnyEvent, most are available via CPAN. 1069 modules come as part of AnyEvent, the others are available via CPAN.
971 1070
972 AnyEvent::Util 1071 AnyEvent::Util
973 Contains various utility functions that replace often-used but 1072 Contains various utility functions that replace often-used blocking
974 blocking functions such as "inet_aton" by event-/callback-based 1073 functions such as "inet_aton" with event/callback-based versions.
975 versions.
976 1074
977 AnyEvent::Socket 1075 AnyEvent::Socket
978 Provides various utility functions for (internet protocol) sockets, 1076 Provides various utility functions for (internet protocol) sockets,
979 addresses and name resolution. Also functions to create non-blocking 1077 addresses and name resolution. Also functions to create non-blocking
980 tcp connections or tcp servers, with IPv6 and SRV record support and 1078 tcp connections or tcp servers, with IPv6 and SRV record support and
981 more. 1079 more.
982 1080
983 AnyEvent::Handle 1081 AnyEvent::Handle
984 Provide read and write buffers, manages watchers for reads and 1082 Provide read and write buffers, manages watchers for reads and
985 writes, supports raw and formatted I/O, I/O queued and fully 1083 writes, supports raw and formatted I/O, I/O queued and fully
986 transparent and non-blocking SSL/TLS (via AnyEvent::TLS. 1084 transparent and non-blocking SSL/TLS (via AnyEvent::TLS).
987 1085
988 AnyEvent::DNS 1086 AnyEvent::DNS
989 Provides rich asynchronous DNS resolver capabilities. 1087 Provides rich asynchronous DNS resolver capabilities.
990 1088
1089 AnyEvent::HTTP, AnyEvent::IRC, AnyEvent::XMPP, AnyEvent::GPSD,
1090 AnyEvent::IGS, AnyEvent::FCP
1091 Implement event-based interfaces to the protocols of the same name
1092 (for the curious, IGS is the International Go Server and FCP is the
1093 Freenet Client Protocol).
1094
1095 AnyEvent::Handle::UDP
1096 Here be danger!
1097
1098 As Pauli would put it, "Not only is it not right, it's not even
1099 wrong!" - there are so many things wrong with AnyEvent::Handle::UDP,
1100 most notably its use of a stream-based API with a protocol that
1101 isn't streamable, that the only way to improve it is to delete it.
1102
1103 It features data corruption (but typically only under load) and
1104 general confusion. On top, the author is not only clueless about UDP
1105 but also fact-resistant - some gems of his understanding: "connect
1106 doesn't work with UDP", "UDP packets are not IP packets", "UDP only
1107 has datagrams, not packets", "I don't need to implement proper error
1108 checking as UDP doesn't support error checking" and so on - he
1109 doesn't even understand what's wrong with his module when it is
1110 explained to him.
1111
991 AnyEvent::HTTP 1112 AnyEvent::DBI
992 A simple-to-use HTTP library that is capable of making a lot of 1113 Executes DBI requests asynchronously in a proxy process for you,
993 concurrent HTTP requests. 1114 notifying you in an event-based way when the operation is finished.
1115
1116 AnyEvent::AIO
1117 Truly asynchronous (as opposed to non-blocking) I/O, should be in
1118 the toolbox of every event programmer. AnyEvent::AIO transparently
1119 fuses IO::AIO and AnyEvent together, giving AnyEvent access to
1120 event-based file I/O, and much more.
994 1121
995 AnyEvent::HTTPD 1122 AnyEvent::HTTPD
996 Provides a simple web application server framework. 1123 A simple embedded webserver.
997 1124
998 AnyEvent::FastPing 1125 AnyEvent::FastPing
999 The fastest ping in the west. 1126 The fastest ping in the west.
1000
1001 AnyEvent::DBI
1002 Executes DBI requests asynchronously in a proxy process.
1003
1004 AnyEvent::AIO
1005 Truly asynchronous I/O, should be in the toolbox of every event
1006 programmer. AnyEvent::AIO transparently fuses IO::AIO and AnyEvent
1007 together.
1008
1009 AnyEvent::BDB
1010 Truly asynchronous Berkeley DB access. AnyEvent::BDB transparently
1011 fuses BDB and AnyEvent together.
1012
1013 AnyEvent::GPSD
1014 A non-blocking interface to gpsd, a daemon delivering GPS
1015 information.
1016
1017 AnyEvent::IRC
1018 AnyEvent based IRC client module family (replacing the older
1019 Net::IRC3).
1020
1021 AnyEvent::XMPP
1022 AnyEvent based XMPP (Jabber protocol) module family (replacing the
1023 older Net::XMPP2>.
1024
1025 AnyEvent::IGS
1026 A non-blocking interface to the Internet Go Server protocol (used by
1027 App::IGS).
1028
1029 Net::FCP
1030 AnyEvent-based implementation of the Freenet Client Protocol,
1031 birthplace of AnyEvent.
1032
1033 Event::ExecFlow
1034 High level API for event-based execution flow control.
1035 1127
1036 Coro 1128 Coro
1037 Has special support for AnyEvent via Coro::AnyEvent. 1129 Has special support for AnyEvent via Coro::AnyEvent.
1038 1130
1039SIMPLIFIED AE API 1131SIMPLIFIED AE API
1040 Starting with version 5.0, AnyEvent officially supports a second, much 1132 Starting with version 5.0, AnyEvent officially supports a second, much
1041 simpler, API that is designed to reduce the calling, typing and memory 1133 simpler, API that is designed to reduce the calling, typing and memory
1042 overhead. 1134 overhead by using function call syntax and a fixed number of parameters.
1043 1135
1044 See the AE manpage for details. 1136 See the AE manpage for details.
1045 1137
1046ERROR AND EXCEPTION HANDLING 1138ERROR AND EXCEPTION HANDLING
1047 In general, AnyEvent does not do any error handling - it relies on the 1139 In general, AnyEvent does not do any error handling - it relies on the
1090 thoroughly check the arguments passed to most method calls. If it 1182 thoroughly check the arguments passed to most method calls. If it
1091 finds any problems, it will croak. 1183 finds any problems, it will croak.
1092 1184
1093 In other words, enables "strict" mode. 1185 In other words, enables "strict" mode.
1094 1186
1095 Unlike "use strict" (or it's modern cousin, "use common::sense", it 1187 Unlike "use strict" (or its modern cousin, "use common::sense", it
1096 is definitely recommended to keep it off in production. Keeping 1188 is definitely recommended to keep it off in production. Keeping
1097 "PERL_ANYEVENT_STRICT=1" in your environment while developing 1189 "PERL_ANYEVENT_STRICT=1" in your environment while developing
1098 programs can be very useful, however. 1190 programs can be very useful, however.
1099 1191
1192 "PERL_ANYEVENT_DEBUG_SHELL"
1193 If this env variable is set, then its contents will be interpreted
1194 by "AnyEvent::Socket::parse_hostport" (after replacing every
1195 occurance of $$ by the process pid) and an "AnyEvent::Debug::shell"
1196 is bound on that port. The shell object is saved in
1197 $AnyEvent::Debug::SHELL.
1198
1199 This takes place when the first watcher is created.
1200
1201 For example, to bind a debug shell on a unix domain socket in
1202 /tmp/debug<pid>.sock, you could use this:
1203
1204 PERL_ANYEVENT_DEBUG_SHELL=unix/:/tmp/debug\$\$.sock perlprog
1205
1206 Note that creating sockets in /tmp is very unsafe on multiuser
1207 systems.
1208
1209 "PERL_ANYEVENT_DEBUG_WRAP"
1210 Can be set to 0, 1 or 2 and enables wrapping of all watchers for
1211 debugging purposes. See "AnyEvent::Debug::wrap" for details.
1212
1100 "PERL_ANYEVENT_MODEL" 1213 "PERL_ANYEVENT_MODEL"
1101 This can be used to specify the event model to be used by AnyEvent, 1214 This can be used to specify the event model to be used by AnyEvent,
1102 before auto detection and -probing kicks in. It must be a string 1215 before auto detection and -probing kicks in.
1103 consisting entirely of ASCII letters. The string "AnyEvent::Impl::" 1216
1104 gets prepended and the resulting module name is loaded and if the 1217 It normally is a string consisting entirely of ASCII letters (e.g.
1105 load was successful, used as event model. If it fails to load 1218 "EV" or "IOAsync"). The string "AnyEvent::Impl::" gets prepended and
1219 the resulting module name is loaded and - if the load was successful
1220 - used as event model backend. If it fails to load then AnyEvent
1106 AnyEvent will proceed with auto detection and -probing. 1221 will proceed with auto detection and -probing.
1107 1222
1108 This functionality might change in future versions. 1223 If the string ends with "::" instead (e.g. "AnyEvent::Impl::EV::")
1224 then nothing gets prepended and the module name is used as-is (hint:
1225 "::" at the end of a string designates a module name and quotes it
1226 appropriately).
1109 1227
1110 For example, to force the pure perl model (AnyEvent::Impl::Perl) you 1228 For example, to force the pure perl model (AnyEvent::Loop::Perl) you
1111 could start your program like this: 1229 could start your program like this:
1112 1230
1113 PERL_ANYEVENT_MODEL=Perl perl ... 1231 PERL_ANYEVENT_MODEL=Perl perl ...
1114 1232
1115 "PERL_ANYEVENT_PROTOCOLS" 1233 "PERL_ANYEVENT_PROTOCOLS"
1312 1430
1313 The actual code goes further and collects all errors ("die"s, 1431 The actual code goes further and collects all errors ("die"s,
1314 exceptions) that occurred during request processing. The "result" method 1432 exceptions) that occurred during request processing. The "result" method
1315 detects whether an exception as thrown (it is stored inside the $txn 1433 detects whether an exception as thrown (it is stored inside the $txn
1316 object) and just throws the exception, which means connection errors and 1434 object) and just throws the exception, which means connection errors and
1317 other problems get reported tot he code that tries to use the result, 1435 other problems get reported to the code that tries to use the result,
1318 not in a random callback. 1436 not in a random callback.
1319 1437
1320 All of this enables the following usage styles: 1438 All of this enables the following usage styles:
1321 1439
1322 1. Blocking: 1440 1. Blocking:
1696 1814
1697 Feel free to install your own handler, or reset it to defaults. 1815 Feel free to install your own handler, or reset it to defaults.
1698 1816
1699RECOMMENDED/OPTIONAL MODULES 1817RECOMMENDED/OPTIONAL MODULES
1700 One of AnyEvent's main goals is to be 100% Pure-Perl(tm): only perl (and 1818 One of AnyEvent's main goals is to be 100% Pure-Perl(tm): only perl (and
1701 it's built-in modules) are required to use it. 1819 its built-in modules) are required to use it.
1702 1820
1703 That does not mean that AnyEvent won't take advantage of some additional 1821 That does not mean that AnyEvent won't take advantage of some additional
1704 modules if they are installed. 1822 modules if they are installed.
1705 1823
1706 This section epxlains which additional modules will be used, and how 1824 This section explains which additional modules will be used, and how
1707 they affect AnyEvent's operetion. 1825 they affect AnyEvent's operation.
1708 1826
1709 Async::Interrupt 1827 Async::Interrupt
1710 This slightly arcane module is used to implement fast signal 1828 This slightly arcane module is used to implement fast signal
1711 handling: To my knowledge, there is no way to do completely 1829 handling: To my knowledge, there is no way to do completely
1712 race-free and quick signal handling in pure perl. To ensure that 1830 race-free and quick signal handling in pure perl. To ensure that
1715 10 seconds, look for $AnyEvent::MAX_SIGNAL_LATENCY). 1833 10 seconds, look for $AnyEvent::MAX_SIGNAL_LATENCY).
1716 1834
1717 If this module is available, then it will be used to implement 1835 If this module is available, then it will be used to implement
1718 signal catching, which means that signals will not be delayed, and 1836 signal catching, which means that signals will not be delayed, and
1719 the event loop will not be interrupted regularly, which is more 1837 the event loop will not be interrupted regularly, which is more
1720 efficient (And good for battery life on laptops). 1838 efficient (and good for battery life on laptops).
1721 1839
1722 This affects not just the pure-perl event loop, but also other event 1840 This affects not just the pure-perl event loop, but also other event
1723 loops that have no signal handling on their own (e.g. Glib, Tk, Qt). 1841 loops that have no signal handling on their own (e.g. Glib, Tk, Qt).
1724 1842
1725 Some event loops (POE, Event, Event::Lib) offer signal watchers 1843 Some event loops (POE, Event, Event::Lib) offer signal watchers
1735 clock is available, can take avdantage of advanced kernel interfaces 1853 clock is available, can take avdantage of advanced kernel interfaces
1736 such as "epoll" and "kqueue", and is the fastest backend *by far*. 1854 such as "epoll" and "kqueue", and is the fastest backend *by far*.
1737 You can even embed Glib/Gtk2 in it (or vice versa, see EV::Glib and 1855 You can even embed Glib/Gtk2 in it (or vice versa, see EV::Glib and
1738 Glib::EV). 1856 Glib::EV).
1739 1857
1858 If you only use backends that rely on another event loop (e.g.
1859 "Tk"), then this module will do nothing for you.
1860
1740 Guard 1861 Guard
1741 The guard module, when used, will be used to implement 1862 The guard module, when used, will be used to implement
1742 "AnyEvent::Util::guard". This speeds up guards considerably (and 1863 "AnyEvent::Util::guard". This speeds up guards considerably (and
1743 uses a lot less memory), but otherwise doesn't affect guard 1864 uses a lot less memory), but otherwise doesn't affect guard
1744 operation much. It is purely used for performance. 1865 operation much. It is purely used for performance.
1745 1866
1746 JSON and JSON::XS 1867 JSON and JSON::XS
1747 This module is required when you want to read or write JSON data via 1868 One of these modules is required when you want to read or write JSON
1748 AnyEvent::Handle. It is also written in pure-perl, but can take 1869 data via AnyEvent::Handle. JSON is also written in pure-perl, but
1749 advantage of the ultra-high-speed JSON::XS module when it is 1870 can take advantage of the ultra-high-speed JSON::XS module when it
1750 installed. 1871 is installed.
1751
1752 In fact, AnyEvent::Handle will use JSON::XS by default if it is
1753 installed.
1754 1872
1755 Net::SSLeay 1873 Net::SSLeay
1756 Implementing TLS/SSL in Perl is certainly interesting, but not very 1874 Implementing TLS/SSL in Perl is certainly interesting, but not very
1757 worthwhile: If this module is installed, then AnyEvent::Handle (with 1875 worthwhile: If this module is installed, then AnyEvent::Handle (with
1758 the help of AnyEvent::TLS), gains the ability to do TLS/SSL. 1876 the help of AnyEvent::TLS), gains the ability to do TLS/SSL.
1759 1877
1760 Time::HiRes 1878 Time::HiRes
1761 This module is part of perl since release 5.008. It will be used 1879 This module is part of perl since release 5.008. It will be used
1762 when the chosen event library does not come with a timing source on 1880 when the chosen event library does not come with a timing source of
1763 it's own. The pure-perl event loop (AnyEvent::Impl::Perl) will 1881 its own. The pure-perl event loop (AnyEvent::Loop) will additionally
1764 additionally use it to try to use a monotonic clock for timing 1882 load it to try to use a monotonic clock for timing stability.
1765 stability.
1766 1883
1767FORK 1884FORK
1768 Most event libraries are not fork-safe. The ones who are usually are 1885 Most event libraries are not fork-safe. The ones who are usually are
1769 because they rely on inefficient but fork-safe "select" or "poll" calls. 1886 because they rely on inefficient but fork-safe "select" or "poll" calls
1770 Only EV is fully fork-aware. 1887 - higher performance APIs such as BSD's kqueue or the dreaded Linux
1888 epoll are usually badly thought-out hacks that are incompatible with
1889 fork in one way or another. Only EV is fully fork-aware and ensures that
1890 you continue event-processing in both parent and child (or both, if you
1891 know what you are doing).
1892
1893 This means that, in general, you cannot fork and do event processing in
1894 the child if the event library was initialised before the fork (which
1895 usually happens when the first AnyEvent watcher is created, or the
1896 library is loaded).
1771 1897
1772 If you have to fork, you must either do so *before* creating your first 1898 If you have to fork, you must either do so *before* creating your first
1773 watcher OR you must not use AnyEvent at all in the child OR you must do 1899 watcher OR you must not use AnyEvent at all in the child OR you must do
1774 something completely out of the scope of AnyEvent. 1900 something completely out of the scope of AnyEvent.
1901
1902 The problem of doing event processing in the parent *and* the child is
1903 much more complicated: even for backends that *are* fork-aware or
1904 fork-safe, their behaviour is not usually what you want: fork clones all
1905 watchers, that means all timers, I/O watchers etc. are active in both
1906 parent and child, which is almost never what you want. USing "exec" to
1907 start worker children from some kind of manage rprocess is usually
1908 preferred, because it is much easier and cleaner, at the expense of
1909 having to have another binary.
1775 1910
1776SECURITY CONSIDERATIONS 1911SECURITY CONSIDERATIONS
1777 AnyEvent can be forced to load any event model via 1912 AnyEvent can be forced to load any event model via
1778 $ENV{PERL_ANYEVENT_MODEL}. While this cannot (to my knowledge) be used 1913 $ENV{PERL_ANYEVENT_MODEL}. While this cannot (to my knowledge) be used
1779 to execute arbitrary code or directly gain access, it can easily be used 1914 to execute arbitrary code or directly gain access, it can easily be used
1803 5.10 and check wether the leaks still show up. (Perl 5.10.0 has other 1938 5.10 and check wether the leaks still show up. (Perl 5.10.0 has other
1804 annoying memleaks, such as leaking on "map" and "grep" but it is usually 1939 annoying memleaks, such as leaking on "map" and "grep" but it is usually
1805 not as pronounced). 1940 not as pronounced).
1806 1941
1807SEE ALSO 1942SEE ALSO
1943 Tutorial/Introduction: AnyEvent::Intro.
1944
1945 FAQ: AnyEvent::FAQ.
1946
1808 Utility functions: AnyEvent::Util. 1947 Utility functions: AnyEvent::Util.
1809 1948
1810 Event modules: EV, EV::Glib, Glib::EV, Event, Glib::Event, Glib, Tk, 1949 Event modules: AnyEvent::Loop, EV, EV::Glib, Glib::EV, Event,
1811 Event::Lib, Qt, POE. 1950 Glib::Event, Glib, Tk, Event::Lib, Qt, POE.
1812 1951
1813 Implementations: AnyEvent::Impl::EV, AnyEvent::Impl::Event, 1952 Implementations: AnyEvent::Impl::EV, AnyEvent::Impl::Event,
1814 AnyEvent::Impl::Glib, AnyEvent::Impl::Tk, AnyEvent::Impl::Perl, 1953 AnyEvent::Impl::Glib, AnyEvent::Impl::Tk, AnyEvent::Impl::Perl,
1815 AnyEvent::Impl::EventLib, AnyEvent::Impl::Qt, AnyEvent::Impl::POE, 1954 AnyEvent::Impl::EventLib, AnyEvent::Impl::Qt, AnyEvent::Impl::POE,
1816 AnyEvent::Impl::IOAsync, Anyevent::Impl::Irssi. 1955 AnyEvent::Impl::IOAsync, Anyevent::Impl::Irssi.
1818 Non-blocking file handles, sockets, TCP clients and servers: 1957 Non-blocking file handles, sockets, TCP clients and servers:
1819 AnyEvent::Handle, AnyEvent::Socket, AnyEvent::TLS. 1958 AnyEvent::Handle, AnyEvent::Socket, AnyEvent::TLS.
1820 1959
1821 Asynchronous DNS: AnyEvent::DNS. 1960 Asynchronous DNS: AnyEvent::DNS.
1822 1961
1823 Coroutine support: Coro, Coro::AnyEvent, Coro::EV, Coro::Event, 1962 Thread support: Coro, Coro::AnyEvent, Coro::EV, Coro::Event.
1824 1963
1825 Nontrivial usage examples: AnyEvent::GPSD, AnyEvent::XMPP, 1964 Nontrivial usage examples: AnyEvent::GPSD, AnyEvent::IRC,
1826 AnyEvent::HTTP. 1965 AnyEvent::HTTP.
1827 1966
1828AUTHOR 1967AUTHOR
1829 Marc Lehmann <schmorp@schmorp.de> 1968 Marc Lehmann <schmorp@schmorp.de>
1830 http://home.schmorp.de/ 1969 http://home.schmorp.de/

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines