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

Comparing AnyEvent/README (file contents):
Revision 1.58 by root, Sun Dec 20 22:49:52 2009 UTC vs.
Revision 1.70 by root, Fri Apr 13 09:57:41 2012 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, Perl, Event::Lib, Irssi, rxvt-unicode, IO::Async,
5 Qt and POE are various supported event loops/environments. 5 Qt, FLTK 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
399 will not restart syscalls (that includes Async::Interrupt and AnyEvent's 403 will not restart syscalls (that includes Async::Interrupt and AnyEvent's
400 pure perl implementation). 404 pure perl implementation).
401 405
402 Safe/Unsafe Signals 406 Safe/Unsafe Signals
403 Perl signals can be either "safe" (synchronous to opcode handling) or 407 Perl signals can be either "safe" (synchronous to opcode handling) or
404 "unsafe" (asynchronous) - the former might get delayed indefinitely, the 408 "unsafe" (asynchronous) - the former might delay signal delivery
405 latter might corrupt your memory. 409 indefinitely, the latter might corrupt your memory.
406 410
407 AnyEvent signal handlers are, in addition, synchronous to the event 411 AnyEvent signal handlers are, in addition, synchronous to the event
408 loop, i.e. they will not interrupt your running perl program but will 412 loop, i.e. they will not interrupt your running perl program but will
409 only be called as part of the normal event handling (just like timer, 413 only be called as part of the normal event handling (just like timer,
410 I/O etc. callbacks, too). 414 I/O etc. callbacks, too).
411 415
412 Signal Races, Delays and Workarounds 416 Signal Races, Delays and Workarounds
413 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
414 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
415 race-free signal handling in perl, requiring C libraries for this. 419 race-free signal handling in perl, requiring C libraries for this.
416 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
417 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 10
418 in $AnyEvent::MAX_SIGNAL_LATENCY (default: 10 seconds). This variable 422 seconds by default, but can be overriden via
419 can be changed only before the first signal watcher is created, and 423 $ENV{PERL_ANYEVENT_MAX_SIGNAL_LATENCY} or $AnyEvent::MAX_SIGNAL_LATENCY
420 should be left alone otherwise. This variable determines how often 424 - see the "ENVIRONMENT VARIABLES" section for details.
421 AnyEvent polls for signals (in case a wake-up was missed). Higher values
422 will cause fewer spurious wake-ups, which is better for power and CPU
423 saving.
424 425
425 All these problems can be avoided by installing the optional 426 All these problems can be avoided by installing the optional
426 Async::Interrupt module, which works with most event loops. It will not 427 Async::Interrupt module, which works with most event loops. It will not
427 work with inherently broken event loops such as Event or Event::Lib (and 428 work with inherently broken event loops such as Event or Event::Lib (and
428 not with POE currently, as POE does it's own workaround with one-second
429 latency). For those, you just have to suffer the delays. 429 not with POE currently). For those, you just have to suffer the delays.
430 430
431 CHILD PROCESS WATCHERS 431 CHILD PROCESS WATCHERS
432 $w = AnyEvent->child (pid => <process id>, cb => <callback>); 432 $w = AnyEvent->child (pid => <process id>, cb => <callback>);
433 433
434 You can also watch on a child process exit and catch its exit status. 434 You can also watch for a child process exit and catch its exit status.
435 435
436 The child process is specified by the "pid" argument (one some backends, 436 The child process is specified by the "pid" argument (on some backends,
437 using 0 watches for any child process exit, on others this will croak). 437 using 0 watches for any child process exit, on others this will croak).
438 The watcher will be triggered only when the child process has finished 438 The watcher will be triggered only when the child process has finished
439 and an exit status is available, not on any trace events 439 and an exit status is available, not on any trace events
440 (stopped/continued). 440 (stopped/continued).
441 441
462 This means you cannot create a child watcher as the very first thing in 462 This means you cannot create a child watcher as the very first thing in
463 an AnyEvent program, you *have* to create at least one watcher before 463 an AnyEvent program, you *have* to create at least one watcher before
464 you "fork" the child (alternatively, you can call "AnyEvent::detect"). 464 you "fork" the child (alternatively, you can call "AnyEvent::detect").
465 465
466 As most event loops do not support waiting for child events, they will 466 As most event loops do not support waiting for child events, they will
467 be emulated by AnyEvent in most cases, in which the latency and race 467 be emulated by AnyEvent in most cases, in which case the latency and
468 problems mentioned in the description of signal watchers apply. 468 race problems mentioned in the description of signal watchers apply.
469 469
470 Example: fork a process and wait for it 470 Example: fork a process and wait for it
471 471
472 my $done = AnyEvent->condvar; 472 my $done = AnyEvent->condvar;
473 473
486 $done->recv; 486 $done->recv;
487 487
488 IDLE WATCHERS 488 IDLE WATCHERS
489 $w = AnyEvent->idle (cb => <callback>); 489 $w = AnyEvent->idle (cb => <callback>);
490 490
491 Sometimes there is a need to do something, but it is not so important to 491 This will repeatedly invoke the callback after the process becomes idle,
492 do it instantly, but only when there is nothing better to do. This 492 until either the watcher is destroyed or new events have been detected.
493 "nothing better to do" is usually defined to be "no other events need
494 attention by the event loop".
495 493
496 Idle watchers ideally get invoked when the event loop has nothing better 494 Idle watchers are useful when there is a need to do something, but it is
497 to do, just before it would block the process to wait for new events. 495 not so important (or wise) to do it instantly. The callback will be
498 Instead of blocking, the idle watcher is invoked. 496 invoked only when there is "nothing better to do", which is usually
497 defined as "all outstanding events have been handled and no new events
498 have been detected". That means that idle watchers ideally get invoked
499 when the event loop has just polled for new events but none have been
500 detected. Instead of blocking to wait for more events, the idle watchers
501 will be invoked.
499 502
500 Most event loops unfortunately do not really support idle watchers (only 503 Unfortunately, most event loops do not really support idle watchers
501 EV, Event and Glib do it in a usable fashion) - for the rest, AnyEvent 504 (only EV, Event and Glib do it in a usable fashion) - for the rest,
502 will simply call the callback "from time to time". 505 AnyEvent will simply call the callback "from time to time".
503 506
504 Example: read lines from STDIN, but only process them when the program 507 Example: read lines from STDIN, but only process them when the program
505 is otherwise idle: 508 is otherwise idle:
506 509
507 my @lines; # read data 510 my @lines; # read data
533 536
534 AnyEvent is slightly different: it expects somebody else to run the 537 AnyEvent is slightly different: it expects somebody else to run the
535 event loop and will only block when necessary (usually when told by the 538 event loop and will only block when necessary (usually when told by the
536 user). 539 user).
537 540
538 The instrument to do that is called a "condition variable", so called 541 The tool to do that is called a "condition variable", so called because
539 because they represent a condition that must become true. 542 they represent a condition that must become true.
540 543
541 Now is probably a good time to look at the examples further below. 544 Now is probably a good time to look at the examples further below.
542 545
543 Condition variables can be created by calling the "AnyEvent->condvar" 546 Condition variables can be created by calling the "AnyEvent->condvar"
544 method, usually without arguments. The only argument pair allowed is 547 method, usually without arguments. The only argument pair allowed is
549 After creation, the condition variable is "false" until it becomes 552 After creation, the condition variable is "false" until it becomes
550 "true" by calling the "send" method (or calling the condition variable 553 "true" by calling the "send" method (or calling the condition variable
551 as if it were a callback, read about the caveats in the description for 554 as if it were a callback, read about the caveats in the description for
552 the "->send" method). 555 the "->send" method).
553 556
554 Condition variables are similar to callbacks, except that you can 557 Since condition variables are the most complex part of the AnyEvent API,
555 optionally wait for them. They can also be called merge points - points 558 here are some different mental models of what they are - pick the ones
556 in time where multiple outstanding events have been processed. And yet 559 you can connect to:
557 another way to call them is transactions - each condition variable can 560
558 be used to represent a transaction, which finishes at some point and 561 * Condition variables are like callbacks - you can call them (and pass
559 delivers a result. And yet some people know them as "futures" - a 562 them instead of callbacks). Unlike callbacks however, you can also
560 promise to compute/deliver something that you can wait for. 563 wait for them to be called.
564
565 * Condition variables are signals - one side can emit or send them,
566 the other side can wait for them, or install a handler that is
567 called when the signal fires.
568
569 * Condition variables are like "Merge Points" - points in your program
570 where you merge multiple independent results/control flows into one.
571
572 * Condition variables represent a transaction - functions that start
573 some kind of transaction can return them, leaving the caller the
574 choice between waiting in a blocking fashion, or setting a callback.
575
576 * Condition variables represent future values, or promises to deliver
577 some result, long before the result is available.
561 578
562 Condition variables are very useful to signal that something has 579 Condition variables are very useful to signal that something has
563 finished, for example, if you write a module that does asynchronous http 580 finished, for example, if you write a module that does asynchronous http
564 requests, then a condition variable would be the ideal candidate to 581 requests, then a condition variable would be the ideal candidate to
565 signal the availability of results. The user can either act when the 582 signal the availability of results. The user can either act when the
578 595
579 Condition variables are represented by hash refs in perl, and the keys 596 Condition variables are represented by hash refs in perl, and the keys
580 used by AnyEvent itself are all named "_ae_XXX" to make subclassing easy 597 used by AnyEvent itself are all named "_ae_XXX" to make subclassing easy
581 (it is often useful to build your own transaction class on top of 598 (it is often useful to build your own transaction class on top of
582 AnyEvent). To subclass, use "AnyEvent::CondVar" as base class and call 599 AnyEvent). To subclass, use "AnyEvent::CondVar" as base class and call
583 it's "new" method in your own "new" method. 600 its "new" method in your own "new" method.
584 601
585 There are two "sides" to a condition variable - the "producer side" 602 There are two "sides" to a condition variable - the "producer side"
586 which eventually calls "-> send", and the "consumer side", which waits 603 which eventually calls "-> send", and the "consumer side", which waits
587 for the send to occur. 604 for the send to occur.
588 605
589 Example: wait for a timer. 606 Example: wait for a timer.
590 607
591 # wait till the result is ready 608 # condition: "wait till the timer is fired"
592 my $result_ready = AnyEvent->condvar; 609 my $timer_fired = AnyEvent->condvar;
593 610
594 # do something such as adding a timer 611 # create the timer - we could wait for, say
595 # or socket watcher the calls $result_ready->send 612 # a handle becomign ready, or even an
596 # when the "result" is ready. 613 # AnyEvent::HTTP request to finish, but
597 # in this case, we simply use a timer: 614 # in this case, we simply use a timer:
598 my $w = AnyEvent->timer ( 615 my $w = AnyEvent->timer (
599 after => 1, 616 after => 1,
600 cb => sub { $result_ready->send }, 617 cb => sub { $timer_fired->send },
601 ); 618 );
602 619
603 # this "blocks" (while handling events) till the callback 620 # this "blocks" (while handling events) till the callback
604 # calls ->send 621 # calls ->send
605 $result_ready->recv; 622 $timer_fired->recv;
606 623
607 Example: wait for a timer, but take advantage of the fact that condition 624 Example: wait for a timer, but take advantage of the fact that condition
608 variables are also callable directly. 625 variables are also callable directly.
609 626
610 my $done = AnyEvent->condvar; 627 my $done = AnyEvent->condvar;
648 Condition variables are overloaded so one can call them directly (as 665 Condition variables are overloaded so one can call them directly (as
649 if they were a code reference). Calling them directly is the same as 666 if they were a code reference). Calling them directly is the same as
650 calling "send". 667 calling "send".
651 668
652 $cv->croak ($error) 669 $cv->croak ($error)
653 Similar to send, but causes all call's to "->recv" to invoke 670 Similar to send, but causes all calls to "->recv" to invoke
654 "Carp::croak" with the given error message/object/scalar. 671 "Carp::croak" with the given error message/object/scalar.
655 672
656 This can be used to signal any errors to the condition variable 673 This can be used to signal any errors to the condition variable
657 user/consumer. Doing it this way instead of calling "croak" directly 674 user/consumer. Doing it this way instead of calling "croak" directly
658 delays the error detetcion, but has the overwhelmign advantage that 675 delays the error detection, but has the overwhelming advantage that
659 it diagnoses the error at the place where the result is expected, 676 it diagnoses the error at the place where the result is expected,
660 and not deep in some event clalback without connection to the actual 677 and not deep in some event callback with no connection to the actual
661 code causing the problem. 678 code causing the problem.
662 679
663 $cv->begin ([group callback]) 680 $cv->begin ([group callback])
664 $cv->end 681 $cv->end
665 These two methods can be used to combine many transactions/events 682 These two methods can be used to combine many transactions/events
702 there is one call to "begin", so the condvar waits for all calls to 719 there is one call to "begin", so the condvar waits for all calls to
703 "end" before sending. 720 "end" before sending.
704 721
705 The ping example mentioned above is slightly more complicated, as 722 The ping example mentioned above is slightly more complicated, as
706 the there are results to be passwd back, and the number of tasks 723 the there are results to be passwd back, and the number of tasks
707 that are begung can potentially be zero: 724 that are begun can potentially be zero:
708 725
709 my $cv = AnyEvent->condvar; 726 my $cv = AnyEvent->condvar;
710 727
711 my %result; 728 my %result;
712 $cv->begin (sub { shift->send (\%result) }); 729 $cv->begin (sub { shift->send (\%result) });
733 callback to be called once the counter reaches 0, and second, it 750 callback to be called once the counter reaches 0, and second, it
734 ensures that "send" is called even when "no" hosts are being pinged 751 ensures that "send" is called even when "no" hosts are being pinged
735 (the loop doesn't execute once). 752 (the loop doesn't execute once).
736 753
737 This is the general pattern when you "fan out" into multiple (but 754 This is the general pattern when you "fan out" into multiple (but
738 potentially none) subrequests: use an outer "begin"/"end" pair to 755 potentially zero) subrequests: use an outer "begin"/"end" pair to
739 set the callback and ensure "end" is called at least once, and then, 756 set the callback and ensure "end" is called at least once, and then,
740 for each subrequest you start, call "begin" and for each subrequest 757 for each subrequest you start, call "begin" and for each subrequest
741 you finish, call "end". 758 you finish, call "end".
742 759
743 METHODS FOR CONSUMERS 760 METHODS FOR CONSUMERS
744 These methods should only be used by the consuming side, i.e. the code 761 These methods should only be used by the consuming side, i.e. the code
745 awaits the condition. 762 awaits the condition.
746 763
747 $cv->recv 764 $cv->recv
748 Wait (blocking if necessary) until the "->send" or "->croak" methods 765 Wait (blocking if necessary) until the "->send" or "->croak" methods
749 have been called on c<$cv>, while servicing other watchers normally. 766 have been called on $cv, while servicing other watchers normally.
750 767
751 You can only wait once on a condition - additional calls are valid 768 You can only wait once on a condition - additional calls are valid
752 but will return immediately. 769 but will return immediately.
753 770
754 If an error condition has been set by calling "->croak", then this 771 If an error condition has been set by calling "->croak", then this
771 example, by coupling condition variables with some kind of request 788 example, by coupling condition variables with some kind of request
772 results and supporting callbacks so the caller knows that getting 789 results and supporting callbacks so the caller knows that getting
773 the result will not block, while still supporting blocking waits if 790 the result will not block, while still supporting blocking waits if
774 the caller so desires). 791 the caller so desires).
775 792
776 You can ensure that "-recv" never blocks by setting a callback and 793 You can ensure that "->recv" never blocks by setting a callback and
777 only calling "->recv" from within that callback (or at a later 794 only calling "->recv" from within that callback (or at a later
778 time). This will work even when the event loop does not support 795 time). This will work even when the event loop does not support
779 blocking waits otherwise. 796 blocking waits otherwise.
780 797
781 $bool = $cv->ready 798 $bool = $cv->ready
784 801
785 $cb = $cv->cb ($cb->($cv)) 802 $cb = $cv->cb ($cb->($cv))
786 This is a mutator function that returns the callback set and 803 This is a mutator function that returns the callback set and
787 optionally replaces it before doing so. 804 optionally replaces it before doing so.
788 805
789 The callback will be called when the condition becomes (or already 806 The callback will be called when the condition becomes "true", i.e.
790 was) "true", i.e. when "send" or "croak" are called (or were 807 when "send" or "croak" are called, with the only argument being the
791 called), with the only argument being the condition variable itself. 808 condition variable itself. If the condition is already true, the
792 Calling "recv" inside the callback or at any later time is 809 callback is called immediately when it is set. Calling "recv" inside
793 guaranteed not to block. 810 the callback or at any later time is guaranteed not to block.
794 811
795SUPPORTED EVENT LOOPS/BACKENDS 812SUPPORTED EVENT LOOPS/BACKENDS
796 The available backend classes are (every class has its own manpage): 813 The available backend classes are (every class has its own manpage):
797 814
798 Backends that are autoprobed when no other event loop can be found. 815 Backends that are autoprobed when no other event loop can be found.
800 use. If EV is not installed, then AnyEvent will fall back to its own 817 use. If EV is not installed, then AnyEvent will fall back to its own
801 pure-perl implementation, which is available everywhere as it comes 818 pure-perl implementation, which is available everywhere as it comes
802 with AnyEvent itself. 819 with AnyEvent itself.
803 820
804 AnyEvent::Impl::EV based on EV (interface to libev, best choice). 821 AnyEvent::Impl::EV based on EV (interface to libev, best choice).
805 AnyEvent::Impl::Perl pure-perl implementation, fast and portable. 822 AnyEvent::Impl::Perl pure-perl AnyEvent::Loop, fast and portable.
806 823
807 Backends that are transparently being picked up when they are used. 824 Backends that are transparently being picked up when they are used.
808 These will be used when they are currently loaded when the first 825 These will be used if they are already loaded when the first watcher
809 watcher is created, in which case it is assumed that the application 826 is created, in which case it is assumed that the application is
810 is using them. This means that AnyEvent will automatically pick the 827 using them. This means that AnyEvent will automatically pick the
811 right backend when the main program loads an event module before 828 right backend when the main program loads an event module before
812 anything starts to create watchers. Nothing special needs to be done 829 anything starts to create watchers. Nothing special needs to be done
813 by the main program. 830 by the main program.
814 831
815 AnyEvent::Impl::Event based on Event, very stable, few glitches. 832 AnyEvent::Impl::Event based on Event, very stable, few glitches.
816 AnyEvent::Impl::Glib based on Glib, slow but very stable. 833 AnyEvent::Impl::Glib based on Glib, slow but very stable.
817 AnyEvent::Impl::Tk based on Tk, very broken. 834 AnyEvent::Impl::Tk based on Tk, very broken.
818 AnyEvent::Impl::EventLib based on Event::Lib, leaks memory and worse. 835 AnyEvent::Impl::EventLib based on Event::Lib, leaks memory and worse.
819 AnyEvent::Impl::POE based on POE, very slow, some limitations. 836 AnyEvent::Impl::POE based on POE, very slow, some limitations.
820 AnyEvent::Impl::Irssi used when running within irssi. 837 AnyEvent::Impl::Irssi used when running within irssi.
838 AnyEvent::Impl::IOAsync based on IO::Async.
839 AnyEvent::Impl::Cocoa based on Cocoa::EventLoop.
840 AnyEvent::Impl::FLTK based on FLTK (fltk 2 binding).
821 841
822 Backends with special needs. 842 Backends with special needs.
823 Qt requires the Qt::Application to be instantiated first, but will 843 Qt requires the Qt::Application to be instantiated first, but will
824 otherwise be picked up automatically. As long as the main program 844 otherwise be picked up automatically. As long as the main program
825 instantiates the application before any AnyEvent watchers are 845 instantiates the application before any AnyEvent watchers are
826 created, everything should just work. 846 created, everything should just work.
827 847
828 AnyEvent::Impl::Qt based on Qt. 848 AnyEvent::Impl::Qt based on Qt.
829 849
830 Support for IO::Async can only be partial, as it is too broken and
831 architecturally limited to even support the AnyEvent API. It also is
832 the only event loop that needs the loop to be set explicitly, so it
833 can only be used by a main program knowing about AnyEvent. See
834 AnyEvent::Impl::Async for the gory details.
835
836 AnyEvent::Impl::IOAsync based on IO::Async, cannot be autoprobed.
837
838 Event loops that are indirectly supported via other backends. 850 Event loops that are indirectly supported via other backends.
839 Some event loops can be supported via other modules: 851 Some event loops can be supported via other modules:
840 852
841 There is no direct support for WxWidgets (Wx) or Prima. 853 There is no direct support for WxWidgets (Wx) or Prima.
842 854
860 Contains "undef" until the first watcher is being created, before 872 Contains "undef" until the first watcher is being created, before
861 the backend has been autodetected. 873 the backend has been autodetected.
862 874
863 Afterwards it contains the event model that is being used, which is 875 Afterwards it contains the event model that is being used, which is
864 the name of the Perl class implementing the model. This class is 876 the name of the Perl class implementing the model. This class is
865 usually one of the "AnyEvent::Impl:xxx" modules, but can be any 877 usually one of the "AnyEvent::Impl::xxx" modules, but can be any
866 other class in the case AnyEvent has been extended at runtime (e.g. 878 other class in the case AnyEvent has been extended at runtime (e.g.
867 in *rxvt-unicode* it will be "urxvt::anyevent"). 879 in *rxvt-unicode* it will be "urxvt::anyevent").
868 880
869 AnyEvent::detect 881 AnyEvent::detect
870 Returns $AnyEvent::MODEL, forcing autodetection of the event model 882 Returns $AnyEvent::MODEL, forcing autodetection of the event model
871 if necessary. You should only call this function right before you 883 if necessary. You should only call this function right before you
872 would have created an AnyEvent watcher anyway, that is, as late as 884 would have created an AnyEvent watcher anyway, that is, as late as
873 possible at runtime, and not e.g. while initialising of your module. 885 possible at runtime, and not e.g. during initialisation of your
886 module.
887
888 The effect of calling this function is as if a watcher had been
889 created (specifically, actions that happen "when the first watcher
890 is created" happen when calling detetc as well).
874 891
875 If you need to do some initialisation before AnyEvent watchers are 892 If you need to do some initialisation before AnyEvent watchers are
876 created, use "post_detect". 893 created, use "post_detect".
877 894
878 $guard = AnyEvent::post_detect { BLOCK } 895 $guard = AnyEvent::post_detect { BLOCK }
879 Arranges for the code block to be executed as soon as the event 896 Arranges for the code block to be executed as soon as the event
880 model is autodetected (or immediately if this has already happened). 897 model is autodetected (or immediately if that has already happened).
881 898
882 The block will be executed *after* the actual backend has been 899 The block will be executed *after* the actual backend has been
883 detected ($AnyEvent::MODEL is set), but *before* any watchers have 900 detected ($AnyEvent::MODEL is set), but *before* any watchers have
884 been created, so it is possible to e.g. patch @AnyEvent::ISA or do 901 been created, so it is possible to e.g. patch @AnyEvent::ISA or do
885 other initialisations - see the sources of AnyEvent::Strict or 902 other initialisations - see the sources of AnyEvent::Strict or
894 object that automatically removes the callback again when it is 911 object that automatically removes the callback again when it is
895 destroyed (or "undef" when the hook was immediately executed). See 912 destroyed (or "undef" when the hook was immediately executed). See
896 AnyEvent::AIO for a case where this is useful. 913 AnyEvent::AIO for a case where this is useful.
897 914
898 Example: Create a watcher for the IO::AIO module and store it in 915 Example: Create a watcher for the IO::AIO module and store it in
899 $WATCHER. Only do so after the event loop is initialised, though. 916 $WATCHER, but do so only do so after the event loop is initialised.
900 917
901 our WATCHER; 918 our WATCHER;
902 919
903 my $guard = AnyEvent::post_detect { 920 my $guard = AnyEvent::post_detect {
904 $WATCHER = AnyEvent->io (fh => IO::AIO::poll_fileno, poll => 'r', cb => \&IO::AIO::poll_cb); 921 $WATCHER = AnyEvent->io (fh => IO::AIO::poll_fileno, poll => 'r', cb => \&IO::AIO::poll_cb);
911 928
912 $WATCHER ||= $guard; 929 $WATCHER ||= $guard;
913 930
914 @AnyEvent::post_detect 931 @AnyEvent::post_detect
915 If there are any code references in this array (you can "push" to it 932 If there are any code references in this array (you can "push" to it
916 before or after loading AnyEvent), then they will called directly 933 before or after loading AnyEvent), then they will be called directly
917 after the event loop has been chosen. 934 after the event loop has been chosen.
918 935
919 You should check $AnyEvent::MODEL before adding to this array, 936 You should check $AnyEvent::MODEL before adding to this array,
920 though: if it is defined then the event loop has already been 937 though: if it is defined then the event loop has already been
921 detected, and the array will be ignored. 938 detected, and the array will be ignored.
940 # AnyEvent not yet initialised, so make sure to load Coro::AnyEvent 957 # AnyEvent not yet initialised, so make sure to load Coro::AnyEvent
941 # as soon as it is 958 # as soon as it is
942 push @AnyEvent::post_detect, sub { require Coro::AnyEvent }; 959 push @AnyEvent::post_detect, sub { require Coro::AnyEvent };
943 } 960 }
944 961
962 AnyEvent::postpone { BLOCK }
963 Arranges for the block to be executed as soon as possible, but not
964 before the call itself returns. In practise, the block will be
965 executed just before the event loop polls for new events, or shortly
966 afterwards.
967
968 This function never returns anything (to make the "return postpone {
969 ... }" idiom more useful.
970
971 To understand the usefulness of this function, consider a function
972 that asynchronously does something for you and returns some
973 transaction object or guard to let you cancel the operation. For
974 example, "AnyEvent::Socket::tcp_connect":
975
976 # start a conenction attempt unless one is active
977 $self->{connect_guard} ||= AnyEvent::Socket::tcp_connect "www.example.net", 80, sub {
978 delete $self->{connect_guard};
979 ...
980 };
981
982 Imagine that this function could instantly call the callback, for
983 example, because it detects an obvious error such as a negative port
984 number. Invoking the callback before the function returns causes
985 problems however: the callback will be called and will try to delete
986 the guard object. But since the function hasn't returned yet, there
987 is nothing to delete. When the function eventually returns it will
988 assign the guard object to "$self->{connect_guard}", where it will
989 likely never be deleted, so the program thinks it is still trying to
990 connect.
991
992 This is where "AnyEvent::postpone" should be used. Instead of
993 calling the callback directly on error:
994
995 $cb->(undef), return # signal error to callback, BAD!
996 if $some_error_condition;
997
998 It should use "postpone":
999
1000 AnyEvent::postpone { $cb->(undef) }, return # signal error to callback, later
1001 if $some_error_condition;
1002
1003 AnyEvent::log $level, $msg[, @args]
1004 Log the given $msg at the given $level.
1005
1006 If AnyEvent::Log is not loaded then this function makes a simple
1007 test to see whether the message will be logged. If the test succeeds
1008 it will load AnyEvent::Log and call "AnyEvent::Log::log" -
1009 consequently, look at the AnyEvent::Log documentation for details.
1010
1011 If the test fails it will simply return. Right now this happens when
1012 a numerical loglevel is used and it is larger than the level
1013 specified via $ENV{PERL_ANYEVENT_VERBOSE}.
1014
1015 If you want to sprinkle loads of logging calls around your code,
1016 consider creating a logger callback with the "AnyEvent::Log::logger"
1017 function, which can reduce typing, codesize and can reduce the
1018 logging overhead enourmously.
1019
945WHAT TO DO IN A MODULE 1020WHAT TO DO IN A MODULE
946 As a module author, you should "use AnyEvent" and call AnyEvent methods 1021 As a module author, you should "use AnyEvent" and call AnyEvent methods
947 freely, but you should not load a specific event module or rely on it. 1022 freely, but you should not load a specific event module or rely on it.
948 1023
949 Be careful when you create watchers in the module body - AnyEvent will 1024 Be careful when you create watchers in the module body - AnyEvent will
956 stall the whole program, and the whole point of using events is to stay 1031 stall the whole program, and the whole point of using events is to stay
957 interactive. 1032 interactive.
958 1033
959 It is fine, however, to call "->recv" when the user of your module 1034 It is fine, however, to call "->recv" when the user of your module
960 requests it (i.e. if you create a http request object ad have a method 1035 requests it (i.e. if you create a http request object ad have a method
961 called "results" that returns the results, it should call "->recv" 1036 called "results" that returns the results, it may call "->recv" freely,
962 freely, as the user of your module knows what she is doing. always). 1037 as the user of your module knows what she is doing. Always).
963 1038
964WHAT TO DO IN THE MAIN PROGRAM 1039WHAT TO DO IN THE MAIN PROGRAM
965 There will always be a single main program - the only place that should 1040 There will always be a single main program - the only place that should
966 dictate which event model to use. 1041 dictate which event model to use.
967 1042
968 If it doesn't care, it can just "use AnyEvent" and use it itself, or not 1043 If the program is not event-based, it need not do anything special, even
969 do anything special (it does not need to be event-based) and let 1044 when it depends on a module that uses an AnyEvent. If the program itself
970 AnyEvent decide which implementation to chose if some module relies on 1045 uses AnyEvent, but does not care which event loop is used, all it needs
971 it. 1046 to do is "use AnyEvent". In either case, AnyEvent will choose the best
1047 available loop implementation.
972 1048
973 If the main program relies on a specific event model - for example, in 1049 If the main program relies on a specific event model - for example, in
974 Gtk2 programs you have to rely on the Glib module - you should load the 1050 Gtk2 programs you have to rely on the Glib module - you should load the
975 event module before loading AnyEvent or any module that uses it: 1051 event module before loading AnyEvent or any module that uses it:
976 generally speaking, you should load it as early as possible. The reason 1052 generally speaking, you should load it as early as possible. The reason
977 is that modules might create watchers when they are loaded, and AnyEvent 1053 is that modules might create watchers when they are loaded, and AnyEvent
978 will decide on the event model to use as soon as it creates watchers, 1054 will decide on the event model to use as soon as it creates watchers,
979 and it might chose the wrong one unless you load the correct one 1055 and it might choose the wrong one unless you load the correct one
980 yourself. 1056 yourself.
981 1057
982 You can chose to use a pure-perl implementation by loading the 1058 You can chose to use a pure-perl implementation by loading the
983 "AnyEvent::Impl::Perl" module, which gives you similar behaviour 1059 "AnyEvent::Loop" module, which gives you similar behaviour everywhere,
984 everywhere, but letting AnyEvent chose the model is generally better. 1060 but letting AnyEvent chose the model is generally better.
985 1061
986 MAINLOOP EMULATION 1062 MAINLOOP EMULATION
987 Sometimes (often for short test scripts, or even standalone programs who 1063 Sometimes (often for short test scripts, or even standalone programs who
988 only want to use AnyEvent), you do not want to run a specific event 1064 only want to use AnyEvent), you do not want to run a specific event
989 loop. 1065 loop.
1001 1077
1002OTHER MODULES 1078OTHER MODULES
1003 The following is a non-exhaustive list of additional modules that use 1079 The following is a non-exhaustive list of additional modules that use
1004 AnyEvent as a client and can therefore be mixed easily with other 1080 AnyEvent as a client and can therefore be mixed easily with other
1005 AnyEvent modules and other event loops in the same program. Some of the 1081 AnyEvent modules and other event loops in the same program. Some of the
1006 modules come with AnyEvent, most are available via CPAN. 1082 modules come as part of AnyEvent, the others are available via CPAN (see
1083 <http://search.cpan.org/search?m=module&q=anyevent%3A%3A*> for a longer
1084 non-exhaustive list), and the list is heavily biased towards modules of
1085 the AnyEvent author himself :)
1007 1086
1008 AnyEvent::Util 1087 AnyEvent::Util
1009 Contains various utility functions that replace often-used but 1088 Contains various utility functions that replace often-used blocking
1010 blocking functions such as "inet_aton" by event-/callback-based 1089 functions such as "inet_aton" with event/callback-based versions.
1011 versions.
1012 1090
1013 AnyEvent::Socket 1091 AnyEvent::Socket
1014 Provides various utility functions for (internet protocol) sockets, 1092 Provides various utility functions for (internet protocol) sockets,
1015 addresses and name resolution. Also functions to create non-blocking 1093 addresses and name resolution. Also functions to create non-blocking
1016 tcp connections or tcp servers, with IPv6 and SRV record support and 1094 tcp connections or tcp servers, with IPv6 and SRV record support and
1017 more. 1095 more.
1018 1096
1019 AnyEvent::Handle 1097 AnyEvent::Handle
1020 Provide read and write buffers, manages watchers for reads and 1098 Provide read and write buffers, manages watchers for reads and
1021 writes, supports raw and formatted I/O, I/O queued and fully 1099 writes, supports raw and formatted I/O, I/O queued and fully
1022 transparent and non-blocking SSL/TLS (via AnyEvent::TLS. 1100 transparent and non-blocking SSL/TLS (via AnyEvent::TLS).
1023 1101
1024 AnyEvent::DNS 1102 AnyEvent::DNS
1025 Provides rich asynchronous DNS resolver capabilities. 1103 Provides rich asynchronous DNS resolver capabilities.
1026 1104
1105 AnyEvent::HTTP, AnyEvent::IRC, AnyEvent::XMPP, AnyEvent::GPSD,
1106 AnyEvent::IGS, AnyEvent::FCP
1107 Implement event-based interfaces to the protocols of the same name
1108 (for the curious, IGS is the International Go Server and FCP is the
1109 Freenet Client Protocol).
1110
1027 AnyEvent::HTTP 1111 AnyEvent::AIO
1028 A simple-to-use HTTP library that is capable of making a lot of 1112 Truly asynchronous (as opposed to non-blocking) I/O, should be in
1029 concurrent HTTP requests. 1113 the toolbox of every event programmer. AnyEvent::AIO transparently
1114 fuses IO::AIO and AnyEvent together, giving AnyEvent access to
1115 event-based file I/O, and much more.
1116
1117 AnyEvent::Filesys::Notify
1118 AnyEvent is good for non-blocking stuff, but it can't detect file or
1119 path changes (e.g. "watch this directory for new files", "watch this
1120 file for changes"). The AnyEvent::Filesys::Notify module promises to
1121 do just that in a portbale fashion, supporting inotify on GNU/Linux
1122 and some weird, without doubt broken, stuff on OS X to monitor
1123 files. It can fall back to blocking scans at regular intervals
1124 transparently on other platforms, so it's about as portable as it
1125 gets.
1126
1127 (I haven't used it myself, but I haven't heard anybody complaining
1128 about it yet).
1129
1130 AnyEvent::DBI
1131 Executes DBI requests asynchronously in a proxy process for you,
1132 notifying you in an event-based way when the operation is finished.
1030 1133
1031 AnyEvent::HTTPD 1134 AnyEvent::HTTPD
1032 Provides a simple web application server framework. 1135 A simple embedded webserver.
1033 1136
1034 AnyEvent::FastPing 1137 AnyEvent::FastPing
1035 The fastest ping in the west. 1138 The fastest ping in the west.
1036 1139
1037 AnyEvent::DBI
1038 Executes DBI requests asynchronously in a proxy process.
1039
1040 AnyEvent::AIO
1041 Truly asynchronous I/O, should be in the toolbox of every event
1042 programmer. AnyEvent::AIO transparently fuses IO::AIO and AnyEvent
1043 together.
1044
1045 AnyEvent::BDB
1046 Truly asynchronous Berkeley DB access. AnyEvent::BDB transparently
1047 fuses BDB and AnyEvent together.
1048
1049 AnyEvent::GPSD
1050 A non-blocking interface to gpsd, a daemon delivering GPS
1051 information.
1052
1053 AnyEvent::IRC
1054 AnyEvent based IRC client module family (replacing the older
1055 Net::IRC3).
1056
1057 AnyEvent::XMPP
1058 AnyEvent based XMPP (Jabber protocol) module family (replacing the
1059 older Net::XMPP2>.
1060
1061 AnyEvent::IGS
1062 A non-blocking interface to the Internet Go Server protocol (used by
1063 App::IGS).
1064
1065 Net::FCP
1066 AnyEvent-based implementation of the Freenet Client Protocol,
1067 birthplace of AnyEvent.
1068
1069 Event::ExecFlow
1070 High level API for event-based execution flow control.
1071
1072 Coro 1140 Coro
1073 Has special support for AnyEvent via Coro::AnyEvent. 1141 Has special support for AnyEvent via Coro::AnyEvent, which allows
1142 you to simply invert the flow control - don't call us, we will call
1143 you:
1144
1145 async {
1146 Coro::AnyEvent::sleep 5; # creates a 5s timer and waits for it
1147 print "5 seconds later!\n";
1148
1149 Coro::AnyEvent::readable *STDIN; # uses an I/O watcher
1150 my $line = <STDIN>; # works for ttys
1151
1152 AnyEvent::HTTP::http_get "url", Coro::rouse_cb;
1153 my ($body, $hdr) = Coro::rouse_wait;
1154 };
1074 1155
1075SIMPLIFIED AE API 1156SIMPLIFIED AE API
1076 Starting with version 5.0, AnyEvent officially supports a second, much 1157 Starting with version 5.0, AnyEvent officially supports a second, much
1077 simpler, API that is designed to reduce the calling, typing and memory 1158 simpler, API that is designed to reduce the calling, typing and memory
1078 overhead. 1159 overhead by using function call syntax and a fixed number of parameters.
1079 1160
1080 See the AE manpage for details. 1161 See the AE manpage for details.
1081 1162
1082ERROR AND EXCEPTION HANDLING 1163ERROR AND EXCEPTION HANDLING
1083 In general, AnyEvent does not do any error handling - it relies on the 1164 In general, AnyEvent does not do any error handling - it relies on the
1094 The pure perl event loop simply re-throws the exception (usually within 1175 The pure perl event loop simply re-throws the exception (usually within
1095 "condvar->recv"), the Event and EV modules call "$Event/EV::DIED->()", 1176 "condvar->recv"), the Event and EV modules call "$Event/EV::DIED->()",
1096 Glib uses "install_exception_handler" and so on. 1177 Glib uses "install_exception_handler" and so on.
1097 1178
1098ENVIRONMENT VARIABLES 1179ENVIRONMENT VARIABLES
1099 The following environment variables are used by this module or its 1180 AnyEvent supports a number of environment variables that tune the
1100 submodules. 1181 runtime behaviour. They are usually evaluated when AnyEvent is loaded,
1182 initialised, or a submodule that uses them is loaded. Many of them also
1183 cause AnyEvent to load additional modules - for example,
1184 "PERL_ANYEVENT_DEBUG_WRAP" causes the AnyEvent::Debug module to be
1185 loaded.
1101 1186
1102 Note that AnyEvent will remove *all* environment variables starting with 1187 All the environment variables documented here start with
1103 "PERL_ANYEVENT_" from %ENV when it is loaded while taint mode is 1188 "PERL_ANYEVENT_", which is what AnyEvent considers its own namespace.
1104 enabled. 1189 Other modules are encouraged (but by no means required) to use
1190 "PERL_ANYEVENT_SUBMODULE" if they have registered the
1191 AnyEvent::Submodule namespace on CPAN, for any submodule. For example,
1192 AnyEvent::HTTP could be expected to use "PERL_ANYEVENT_HTTP_PROXY" (it
1193 should not access env variables starting with "AE_", see below).
1194
1195 All variables can also be set via the "AE_" prefix, that is, instead of
1196 setting "PERL_ANYEVENT_VERBOSE" you can also set "AE_VERBOSE". In case
1197 there is a clash btween anyevent and another program that uses
1198 "AE_something" you can set the corresponding "PERL_ANYEVENT_something"
1199 variable to the empty string, as those variables take precedence.
1200
1201 When AnyEvent is first loaded, it copies all "AE_xxx" env variables to
1202 their "PERL_ANYEVENT_xxx" counterpart unless that variable already
1203 exists. If taint mode is on, then AnyEvent will remove *all* environment
1204 variables starting with "PERL_ANYEVENT_" from %ENV (or replace them with
1205 "undef" or the empty string, if the corresaponding "AE_" variable is
1206 set).
1207
1208 The exact algorithm is currently:
1209
1210 1. if taint mode enabled, delete all PERL_ANYEVENT_xyz variables from %ENV
1211 2. copy over AE_xyz to PERL_ANYEVENT_xyz unless the latter alraedy exists
1212 3. if taint mode enabled, set all PERL_ANYEVENT_xyz variables to undef.
1213
1214 This ensures that child processes will not see the "AE_" variables.
1215
1216 The following environment variables are currently known to AnyEvent:
1105 1217
1106 "PERL_ANYEVENT_VERBOSE" 1218 "PERL_ANYEVENT_VERBOSE"
1107 By default, AnyEvent will be completely silent except in fatal 1219 By default, AnyEvent will log messages with loglevel 4 ("error") or
1108 conditions. You can set this environment variable to make AnyEvent 1220 higher (see AnyEvent::Log). You can set this environment variable to
1109 more talkative. 1221 a numerical loglevel to make AnyEvent more (or less) talkative.
1110 1222
1223 If you want to do more than just set the global logging level you
1224 should have a look at "PERL_ANYEVENT_LOG", which allows much more
1225 complex specifications.
1226
1227 When set to 0 ("off"), then no messages whatsoever will be logged
1228 with everything else at defaults.
1229
1111 When set to 1 or higher, causes AnyEvent to warn about unexpected 1230 When set to 5 or higher ("warn"), AnyEvent warns about unexpected
1112 conditions, such as not being able to load the event model specified 1231 conditions, such as not being able to load the event model specified
1113 by "PERL_ANYEVENT_MODEL". 1232 by "PERL_ANYEVENT_MODEL", or a guard callback throwing an exception
1233 - this is the minimum recommended level for use during development.
1114 1234
1115 When set to 2 or higher, cause AnyEvent to report to STDERR which 1235 When set to 7 or higher (info), AnyEvent reports which event model
1116 event model it chooses. 1236 it chooses.
1117 1237
1118 When set to 8 or higher, then AnyEvent will report extra information 1238 When set to 8 or higher (debug), then AnyEvent will report extra
1119 on which optional modules it loads and how it implements certain 1239 information on which optional modules it loads and how it implements
1120 features. 1240 certain features.
1241
1242 "PERL_ANYEVENT_LOG"
1243 Accepts rather complex logging specifications. For example, you
1244 could log all "debug" messages of some module to stderr, warnings
1245 and above to stderr, and errors and above to syslog, with:
1246
1247 PERL_ANYEVENT_LOG=Some::Module=debug,+log:filter=warn,+%syslog:%syslog=error,syslog
1248
1249 For the rather extensive details, see AnyEvent::Log.
1250
1251 This variable is evaluated when AnyEvent (or AnyEvent::Log) is
1252 loaded, so will take effect even before AnyEvent has initialised
1253 itself.
1254
1255 Note that specifying this environment variable causes the
1256 AnyEvent::Log module to be loaded, while "PERL_ANYEVENT_VERBOSE"
1257 does not, so only using the latter saves a few hundred kB of memory
1258 unless a module explicitly needs the extra features of
1259 AnyEvent::Log.
1121 1260
1122 "PERL_ANYEVENT_STRICT" 1261 "PERL_ANYEVENT_STRICT"
1123 AnyEvent does not do much argument checking by default, as thorough 1262 AnyEvent does not do much argument checking by default, as thorough
1124 argument checking is very costly. Setting this variable to a true 1263 argument checking is very costly. Setting this variable to a true
1125 value will cause AnyEvent to load "AnyEvent::Strict" and then to 1264 value will cause AnyEvent to load "AnyEvent::Strict" and then to
1126 thoroughly check the arguments passed to most method calls. If it 1265 thoroughly check the arguments passed to most method calls. If it
1127 finds any problems, it will croak. 1266 finds any problems, it will croak.
1128 1267
1129 In other words, enables "strict" mode. 1268 In other words, enables "strict" mode.
1130 1269
1131 Unlike "use strict" (or it's modern cousin, "use common::sense", it 1270 Unlike "use strict" (or its modern cousin, "use common::sense", it
1132 is definitely recommended to keep it off in production. Keeping 1271 is definitely recommended to keep it off in production. Keeping
1133 "PERL_ANYEVENT_STRICT=1" in your environment while developing 1272 "PERL_ANYEVENT_STRICT=1" in your environment while developing
1134 programs can be very useful, however. 1273 programs can be very useful, however.
1135 1274
1275 "PERL_ANYEVENT_DEBUG_SHELL"
1276 If this env variable is nonempty, then its contents will be
1277 interpreted by "AnyEvent::Socket::parse_hostport" and
1278 "AnyEvent::Debug::shell" (after replacing every occurance of $$ by
1279 the process pid). The shell object is saved in
1280 $AnyEvent::Debug::SHELL.
1281
1282 This happens when the first watcher is created.
1283
1284 For example, to bind a debug shell on a unix domain socket in
1285 /tmp/debug<pid>.sock, you could use this:
1286
1287 PERL_ANYEVENT_DEBUG_SHELL=/tmp/debug\$\$.sock perlprog
1288 # connect with e.g.: socat readline /tmp/debug123.sock
1289
1290 Or to bind to tcp port 4545 on localhost:
1291
1292 PERL_ANYEVENT_DEBUG_SHELL=127.0.0.1:4545 perlprog
1293 # connect with e.g.: telnet localhost 4545
1294
1295 Note that creating sockets in /tmp or on localhost is very unsafe on
1296 multiuser systems.
1297
1298 "PERL_ANYEVENT_DEBUG_WRAP"
1299 Can be set to 0, 1 or 2 and enables wrapping of all watchers for
1300 debugging purposes. See "AnyEvent::Debug::wrap" for details.
1301
1136 "PERL_ANYEVENT_MODEL" 1302 "PERL_ANYEVENT_MODEL"
1137 This can be used to specify the event model to be used by AnyEvent, 1303 This can be used to specify the event model to be used by AnyEvent,
1138 before auto detection and -probing kicks in. It must be a string 1304 before auto detection and -probing kicks in.
1139 consisting entirely of ASCII letters. The string "AnyEvent::Impl::" 1305
1140 gets prepended and the resulting module name is loaded and if the 1306 It normally is a string consisting entirely of ASCII letters (e.g.
1141 load was successful, used as event model. If it fails to load 1307 "EV" or "IOAsync"). The string "AnyEvent::Impl::" gets prepended and
1308 the resulting module name is loaded and - if the load was successful
1309 - used as event model backend. If it fails to load then AnyEvent
1142 AnyEvent will proceed with auto detection and -probing. 1310 will proceed with auto detection and -probing.
1143 1311
1144 This functionality might change in future versions. 1312 If the string ends with "::" instead (e.g. "AnyEvent::Impl::EV::")
1313 then nothing gets prepended and the module name is used as-is (hint:
1314 "::" at the end of a string designates a module name and quotes it
1315 appropriately).
1145 1316
1146 For example, to force the pure perl model (AnyEvent::Impl::Perl) you 1317 For example, to force the pure perl model (AnyEvent::Loop::Perl) you
1147 could start your program like this: 1318 could start your program like this:
1148 1319
1149 PERL_ANYEVENT_MODEL=Perl perl ... 1320 PERL_ANYEVENT_MODEL=Perl perl ...
1321
1322 "PERL_ANYEVENT_IO_MODEL"
1323 The current file I/O model - see AnyEvent::IO for more info.
1324
1325 At the moment, only "Perl" (small, pure-perl, synchronous) and
1326 "IOAIO" (truly asynchronous) are supported. The default is "IOAIO"
1327 if AnyEvent::AIO can be loaded, otherwise it is "Perl".
1150 1328
1151 "PERL_ANYEVENT_PROTOCOLS" 1329 "PERL_ANYEVENT_PROTOCOLS"
1152 Used by both AnyEvent::DNS and AnyEvent::Socket to determine 1330 Used by both AnyEvent::DNS and AnyEvent::Socket to determine
1153 preferences for IPv4 or IPv6. The default is unspecified (and might 1331 preferences for IPv4 or IPv6. The default is unspecified (and might
1154 change, or be the result of auto probing). 1332 change, or be the result of auto probing).
1168 "PERL_ANYEVENT_PROTOCOLS=ipv4" - only support IPv4, never try to 1346 "PERL_ANYEVENT_PROTOCOLS=ipv4" - only support IPv4, never try to
1169 resolve or contact IPv6 addresses. 1347 resolve or contact IPv6 addresses.
1170 "PERL_ANYEVENT_PROTOCOLS=ipv6,ipv4" support either IPv4 or IPv6, but 1348 "PERL_ANYEVENT_PROTOCOLS=ipv6,ipv4" support either IPv4 or IPv6, but
1171 prefer IPv6 over IPv4. 1349 prefer IPv6 over IPv4.
1172 1350
1351 "PERL_ANYEVENT_HOSTS"
1352 This variable, if specified, overrides the /etc/hosts file used by
1353 AnyEvent::Socket"::resolve_sockaddr", i.e. hosts aliases will be
1354 read from that file instead.
1355
1173 "PERL_ANYEVENT_EDNS0" 1356 "PERL_ANYEVENT_EDNS0"
1174 Used by AnyEvent::DNS to decide whether to use the EDNS0 extension 1357 Used by AnyEvent::DNS to decide whether to use the EDNS0 extension
1175 for DNS. This extension is generally useful to reduce DNS traffic, 1358 for DNS. This extension is generally useful to reduce DNS traffic,
1176 but some (broken) firewalls drop such DNS packets, which is why it 1359 especially when DNSSEC is involved, but some (broken) firewalls drop
1177 is off by default. 1360 such DNS packets, which is why it is off by default.
1178 1361
1179 Setting this variable to 1 will cause AnyEvent::DNS to announce 1362 Setting this variable to 1 will cause AnyEvent::DNS to announce
1180 EDNS0 in its DNS requests. 1363 EDNS0 in its DNS requests.
1181 1364
1182 "PERL_ANYEVENT_MAX_FORKS" 1365 "PERL_ANYEVENT_MAX_FORKS"
1186 "PERL_ANYEVENT_MAX_OUTSTANDING_DNS" 1369 "PERL_ANYEVENT_MAX_OUTSTANDING_DNS"
1187 The default value for the "max_outstanding" parameter for the 1370 The default value for the "max_outstanding" parameter for the
1188 default DNS resolver - this is the maximum number of parallel DNS 1371 default DNS resolver - this is the maximum number of parallel DNS
1189 requests that are sent to the DNS server. 1372 requests that are sent to the DNS server.
1190 1373
1374 "PERL_ANYEVENT_MAX_SIGNAL_LATENCY"
1375 Perl has inherently racy signal handling (you can basically choose
1376 between losing signals and memory corruption) - pure perl event
1377 loops (including "AnyEvent::Loop", when "Async::Interrupt" isn't
1378 available) therefore have to poll regularly to avoid losing signals.
1379
1380 Some event loops are racy, but don't poll regularly, and some event
1381 loops are written in C but are still racy. For those event loops,
1382 AnyEvent installs a timer that regularly wakes up the event loop.
1383
1384 By default, the interval for this timer is 10 seconds, but you can
1385 override this delay with this environment variable (or by setting
1386 the $AnyEvent::MAX_SIGNAL_LATENCY variable before creating signal
1387 watchers).
1388
1389 Lower values increase CPU (and energy) usage, higher values can
1390 introduce long delays when reaping children or waiting for signals.
1391
1392 The AnyEvent::Async module, if available, will be used to avoid this
1393 polling (with most event loops).
1394
1191 "PERL_ANYEVENT_RESOLV_CONF" 1395 "PERL_ANYEVENT_RESOLV_CONF"
1192 The file to use instead of /etc/resolv.conf (or OS-specific 1396 The absolute path to a resolv.conf-style file to use instead of
1193 configuration) in the default resolver. When set to the empty 1397 /etc/resolv.conf (or the OS-specific configuration) in the default
1194 string, no default config will be used. 1398 resolver, or the empty string to select the default configuration.
1195 1399
1196 "PERL_ANYEVENT_CA_FILE", "PERL_ANYEVENT_CA_PATH". 1400 "PERL_ANYEVENT_CA_FILE", "PERL_ANYEVENT_CA_PATH".
1197 When neither "ca_file" nor "ca_path" was specified during 1401 When neither "ca_file" nor "ca_path" was specified during
1198 AnyEvent::TLS context creation, and either of these environment 1402 AnyEvent::TLS context creation, and either of these environment
1199 variables exist, they will be used to specify CA certificate 1403 variables are nonempty, they will be used to specify CA certificate
1200 locations instead of a system-dependent default. 1404 locations instead of a system-dependent default.
1201 1405
1202 "PERL_ANYEVENT_AVOID_GUARD" and "PERL_ANYEVENT_AVOID_ASYNC_INTERRUPT" 1406 "PERL_ANYEVENT_AVOID_GUARD" and "PERL_ANYEVENT_AVOID_ASYNC_INTERRUPT"
1203 When these are set to 1, then the respective modules are not loaded. 1407 When these are set to 1, then the respective modules are not loaded.
1204 Mostly good for testing AnyEvent itself. 1408 Mostly good for testing AnyEvent itself.
1348 1552
1349 The actual code goes further and collects all errors ("die"s, 1553 The actual code goes further and collects all errors ("die"s,
1350 exceptions) that occurred during request processing. The "result" method 1554 exceptions) that occurred during request processing. The "result" method
1351 detects whether an exception as thrown (it is stored inside the $txn 1555 detects whether an exception as thrown (it is stored inside the $txn
1352 object) and just throws the exception, which means connection errors and 1556 object) and just throws the exception, which means connection errors and
1353 other problems get reported tot he code that tries to use the result, 1557 other problems get reported to the code that tries to use the result,
1354 not in a random callback. 1558 not in a random callback.
1355 1559
1356 All of this enables the following usage styles: 1560 All of this enables the following usage styles:
1357 1561
1358 1. Blocking: 1562 1. Blocking:
1524 when used without AnyEvent), but most event loops have acceptable 1728 when used without AnyEvent), but most event loops have acceptable
1525 performance with or without AnyEvent. 1729 performance with or without AnyEvent.
1526 1730
1527 * The overhead AnyEvent adds is usually much smaller than the overhead 1731 * The overhead AnyEvent adds is usually much smaller than the overhead
1528 of the actual event loop, only with extremely fast event loops such 1732 of the actual event loop, only with extremely fast event loops such
1529 as EV adds AnyEvent significant overhead. 1733 as EV does AnyEvent add significant overhead.
1530 1734
1531 * You should avoid POE like the plague if you want performance or 1735 * You should avoid POE like the plague if you want performance or
1532 reasonable memory usage. 1736 reasonable memory usage.
1533 1737
1534 BENCHMARKING THE LARGE SERVER CASE 1738 BENCHMARKING THE LARGE SERVER CASE
1732 1936
1733 Feel free to install your own handler, or reset it to defaults. 1937 Feel free to install your own handler, or reset it to defaults.
1734 1938
1735RECOMMENDED/OPTIONAL MODULES 1939RECOMMENDED/OPTIONAL MODULES
1736 One of AnyEvent's main goals is to be 100% Pure-Perl(tm): only perl (and 1940 One of AnyEvent's main goals is to be 100% Pure-Perl(tm): only perl (and
1737 it's built-in modules) are required to use it. 1941 its built-in modules) are required to use it.
1738 1942
1739 That does not mean that AnyEvent won't take advantage of some additional 1943 That does not mean that AnyEvent won't take advantage of some additional
1740 modules if they are installed. 1944 modules if they are installed.
1741 1945
1742 This section explains which additional modules will be used, and how 1946 This section explains which additional modules will be used, and how
1771 clock is available, can take avdantage of advanced kernel interfaces 1975 clock is available, can take avdantage of advanced kernel interfaces
1772 such as "epoll" and "kqueue", and is the fastest backend *by far*. 1976 such as "epoll" and "kqueue", and is the fastest backend *by far*.
1773 You can even embed Glib/Gtk2 in it (or vice versa, see EV::Glib and 1977 You can even embed Glib/Gtk2 in it (or vice versa, see EV::Glib and
1774 Glib::EV). 1978 Glib::EV).
1775 1979
1980 If you only use backends that rely on another event loop (e.g.
1981 "Tk"), then this module will do nothing for you.
1982
1776 Guard 1983 Guard
1777 The guard module, when used, will be used to implement 1984 The guard module, when used, will be used to implement
1778 "AnyEvent::Util::guard". This speeds up guards considerably (and 1985 "AnyEvent::Util::guard". This speeds up guards considerably (and
1779 uses a lot less memory), but otherwise doesn't affect guard 1986 uses a lot less memory), but otherwise doesn't affect guard
1780 operation much. It is purely used for performance. 1987 operation much. It is purely used for performance.
1781 1988
1782 JSON and JSON::XS 1989 JSON and JSON::XS
1783 One of these modules is required when you want to read or write JSON 1990 One of these modules is required when you want to read or write JSON
1784 data via AnyEvent::Handle. It is also written in pure-perl, but can 1991 data via AnyEvent::Handle. JSON is also written in pure-perl, but
1785 take advantage of the ultra-high-speed JSON::XS module when it is 1992 can take advantage of the ultra-high-speed JSON::XS module when it
1786 installed. 1993 is installed.
1787
1788 In fact, AnyEvent::Handle will use JSON::XS by default if it is
1789 installed.
1790 1994
1791 Net::SSLeay 1995 Net::SSLeay
1792 Implementing TLS/SSL in Perl is certainly interesting, but not very 1996 Implementing TLS/SSL in Perl is certainly interesting, but not very
1793 worthwhile: If this module is installed, then AnyEvent::Handle (with 1997 worthwhile: If this module is installed, then AnyEvent::Handle (with
1794 the help of AnyEvent::TLS), gains the ability to do TLS/SSL. 1998 the help of AnyEvent::TLS), gains the ability to do TLS/SSL.
1795 1999
1796 Time::HiRes 2000 Time::HiRes
1797 This module is part of perl since release 5.008. It will be used 2001 This module is part of perl since release 5.008. It will be used
1798 when the chosen event library does not come with a timing source on 2002 when the chosen event library does not come with a timing source of
1799 it's own. The pure-perl event loop (AnyEvent::Impl::Perl) will 2003 its own. The pure-perl event loop (AnyEvent::Loop) will additionally
1800 additionally use it to try to use a monotonic clock for timing 2004 load it to try to use a monotonic clock for timing stability.
1801 stability.
1802 2005
1803FORK 2006FORK
1804 Most event libraries are not fork-safe. The ones who are usually are 2007 Most event libraries are not fork-safe. The ones who are usually are
1805 because they rely on inefficient but fork-safe "select" or "poll" calls. 2008 because they rely on inefficient but fork-safe "select" or "poll" calls
1806 Only EV is fully fork-aware. 2009 - higher performance APIs such as BSD's kqueue or the dreaded Linux
2010 epoll are usually badly thought-out hacks that are incompatible with
2011 fork in one way or another. Only EV is fully fork-aware and ensures that
2012 you continue event-processing in both parent and child (or both, if you
2013 know what you are doing).
1807 2014
1808 This means that, in general, you cannot fork and do event processing in 2015 This means that, in general, you cannot fork and do event processing in
1809 the child if a watcher was created before the fork (which in turn 2016 the child if the event library was initialised before the fork (which
1810 initialises the event library). 2017 usually happens when the first AnyEvent watcher is created, or the
2018 library is loaded).
1811 2019
1812 If you have to fork, you must either do so *before* creating your first 2020 If you have to fork, you must either do so *before* creating your first
1813 watcher OR you must not use AnyEvent at all in the child OR you must do 2021 watcher OR you must not use AnyEvent at all in the child OR you must do
1814 something completely out of the scope of AnyEvent. 2022 something completely out of the scope of AnyEvent.
1815 2023
1816 The problem of doing event processing in the parent *and* the child is 2024 The problem of doing event processing in the parent *and* the child is
1817 much more complicated: even for backends that *are* fork-aware or 2025 much more complicated: even for backends that *are* fork-aware or
1818 fork-safe, their behaviour is not usually what you want: fork clones all 2026 fork-safe, their behaviour is not usually what you want: fork clones all
1819 watchers, that means all timers, I/O watchers etc. are active in both 2027 watchers, that means all timers, I/O watchers etc. are active in both
1820 parent and child, which is almost never what you want. 2028 parent and child, which is almost never what you want. USing "exec" to
2029 start worker children from some kind of manage rprocess is usually
2030 preferred, because it is much easier and cleaner, at the expense of
2031 having to have another binary.
1821 2032
1822SECURITY CONSIDERATIONS 2033SECURITY CONSIDERATIONS
1823 AnyEvent can be forced to load any event model via 2034 AnyEvent can be forced to load any event model via
1824 $ENV{PERL_ANYEVENT_MODEL}. While this cannot (to my knowledge) be used 2035 $ENV{PERL_ANYEVENT_MODEL}. While this cannot (to my knowledge) be used
1825 to execute arbitrary code or directly gain access, it can easily be used 2036 to execute arbitrary code or directly gain access, it can easily be used
1849 5.10 and check wether the leaks still show up. (Perl 5.10.0 has other 2060 5.10 and check wether the leaks still show up. (Perl 5.10.0 has other
1850 annoying memleaks, such as leaking on "map" and "grep" but it is usually 2061 annoying memleaks, such as leaking on "map" and "grep" but it is usually
1851 not as pronounced). 2062 not as pronounced).
1852 2063
1853SEE ALSO 2064SEE ALSO
1854 Utility functions: AnyEvent::Util. 2065 Tutorial/Introduction: AnyEvent::Intro.
1855 2066
1856 Event modules: EV, EV::Glib, Glib::EV, Event, Glib::Event, Glib, Tk, 2067 FAQ: AnyEvent::FAQ.
1857 Event::Lib, Qt, POE. 2068
2069 Utility functions: AnyEvent::Util (misc. grab-bag), AnyEvent::Log
2070 (simply logging).
2071
2072 Development/Debugging: AnyEvent::Strict (stricter checking),
2073 AnyEvent::Debug (interactive shell, watcher tracing).
2074
2075 Supported event modules: AnyEvent::Loop, EV, EV::Glib, Glib::EV, Event,
2076 Glib::Event, Glib, Tk, Event::Lib, Qt, POE, FLTK.
1858 2077
1859 Implementations: AnyEvent::Impl::EV, AnyEvent::Impl::Event, 2078 Implementations: AnyEvent::Impl::EV, AnyEvent::Impl::Event,
1860 AnyEvent::Impl::Glib, AnyEvent::Impl::Tk, AnyEvent::Impl::Perl, 2079 AnyEvent::Impl::Glib, AnyEvent::Impl::Tk, AnyEvent::Impl::Perl,
1861 AnyEvent::Impl::EventLib, AnyEvent::Impl::Qt, AnyEvent::Impl::POE, 2080 AnyEvent::Impl::EventLib, AnyEvent::Impl::Qt, AnyEvent::Impl::POE,
1862 AnyEvent::Impl::IOAsync, Anyevent::Impl::Irssi. 2081 AnyEvent::Impl::IOAsync, Anyevent::Impl::Irssi, AnyEvent::Impl::FLTK.
1863 2082
1864 Non-blocking file handles, sockets, TCP clients and servers: 2083 Non-blocking handles, pipes, stream sockets, TCP clients and servers:
1865 AnyEvent::Handle, AnyEvent::Socket, AnyEvent::TLS. 2084 AnyEvent::Handle, AnyEvent::Socket, AnyEvent::TLS.
1866 2085
2086 Asynchronous File I/O: AnyEvent::IO.
2087
1867 Asynchronous DNS: AnyEvent::DNS. 2088 Asynchronous DNS: AnyEvent::DNS.
1868 2089
1869 Coroutine support: Coro, Coro::AnyEvent, Coro::EV, Coro::Event, 2090 Thread support: Coro, Coro::AnyEvent, Coro::EV, Coro::Event.
1870 2091
1871 Nontrivial usage examples: AnyEvent::GPSD, AnyEvent::XMPP, 2092 Nontrivial usage examples: AnyEvent::GPSD, AnyEvent::IRC,
1872 AnyEvent::HTTP. 2093 AnyEvent::HTTP.
1873 2094
1874AUTHOR 2095AUTHOR
1875 Marc Lehmann <schmorp@schmorp.de> 2096 Marc Lehmann <schmorp@schmorp.de>
1876 http://home.schmorp.de/ 2097 http://anyevent.schmorp.de
1877 2098

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines