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

Comparing AnyEvent/README (file contents):
Revision 1.47 by root, Mon Jul 20 22:39:57 2009 UTC vs.
Revision 1.63 by root, Wed Oct 13 19:49:46 2010 UTC

1NAME 1NAME
2 AnyEvent - events independent of event loop implementation 2 AnyEvent - the DBI of event loop programming
3 3
4 EV, Event, Glib, Tk, Perl, Event::Lib, Qt and POE are various supported 4 EV, Event, Glib, Tk, Perl, Event::Lib, Irssi, rxvt-unicode, IO::Async,
5 event loops. 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 Respository, 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)
51 Glib, POE, IO::Async, Event... CPAN offers event models by the dozen 56 Glib, POE, IO::Async, Event... CPAN offers event models by the dozen
52 nowadays. So what is different about AnyEvent? 57 nowadays. So what is different about AnyEvent?
53 58
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 + IO::Async? No go. Tk + Event? No go. Again: if your
81 module uses one of those, every user of your module has to use it, too. 86 module uses one of those, every user of your module has to use it, too.
82 But if your module uses AnyEvent, it works transparently with all event 87 But if your module uses AnyEvent, it works transparently with all event
83 models it supports (including stuff like IO::Async, as long as those use 88 models it supports (including stuff like IO::Async, as long as those use
84 one of the supported event loops. It is trivial to add new event loops 89 one of 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::Impl::Perl, Event,
116 AnyEvent::Impl::Perl, Tk, Event::Lib, Qt, POE. The first one found is 121 Glib, 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::Impl::Perl should always work, so the other two are not
120 successfully loaded will be used. If, after this, still none could be 125 normally 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
138 "AnyEvent::Impl::Perl". Like other event modules you can load it 142 "AnyEvent::Impl::Perl". Like other event modules you can load it
139 explicitly and enjoy the high availability of that event loop :) 143 explicitly and enjoy the high availability of that event loop :)
140 144
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 });
173 Note that "my $w; $w =" combination. This is necessary because in Perl, 177 Note that "my $w; $w =" combination. This is necessary because in Perl,
174 my variables are only visible after the statement in which they are 178 my variables are only visible after the statement in which they are
175 declared. 179 declared.
176 180
177 I/O WATCHERS 181 I/O WATCHERS
182 $w = AnyEvent->io (
183 fh => <filehandle_or_fileno>,
184 poll => <"r" or "w">,
185 cb => <callback>,
186 );
187
178 You can create an I/O watcher by calling the "AnyEvent->io" method with 188 You can create an I/O watcher by calling the "AnyEvent->io" method with
179 the following mandatory key-value pairs as arguments: 189 the following mandatory key-value pairs as arguments:
180 190
181 "fh" is the Perl *file handle* (or a naked file descriptor) to watch for 191 "fh" is the Perl *file handle* (or a naked file descriptor) to watch for
182 events (AnyEvent might or might not keep a reference to this file 192 events (AnyEvent might or might not keep a reference to this file
196 206
197 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
198 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
199 the underlying file descriptor. 209 the underlying file descriptor.
200 210
201 Some event loops issue spurious readyness notifications, so you should 211 Some event loops issue spurious readiness notifications, so you should
202 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
203 handles. 213 handles.
204 214
205 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
206 watcher. 216 watcher.
210 warn "read: $input\n"; 220 warn "read: $input\n";
211 undef $w; 221 undef $w;
212 }); 222 });
213 223
214 TIME WATCHERS 224 TIME WATCHERS
225 $w = AnyEvent->timer (after => <seconds>, cb => <callback>);
226
227 $w = AnyEvent->timer (
228 after => <fractional_seconds>,
229 interval => <fractional_seconds>,
230 cb => <callback>,
231 );
232
215 You can create a time watcher by calling the "AnyEvent->timer" method 233 You can create a time watcher by calling the "AnyEvent->timer" method
216 with the following mandatory arguments: 234 with the following mandatory arguments:
217 235
218 "after" specifies after how many seconds (fractional values are 236 "after" specifies after how many seconds (fractional values are
219 supported) the callback should be invoked. "cb" is the callback to 237 supported) the callback should be invoked. "cb" is the callback to
221 239
222 Although the callback might get passed parameters, their value and 240 Although the callback might get passed parameters, their value and
223 presence is undefined and you cannot rely on them. Portable AnyEvent 241 presence is undefined and you cannot rely on them. Portable AnyEvent
224 callbacks cannot use arguments passed to time watcher callbacks. 242 callbacks cannot use arguments passed to time watcher callbacks.
225 243
226 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
227 parameter, "interval", as a strictly positive number (> 0), then the 245 parameter, "interval", as a strictly positive number (> 0), then the
228 callback will be invoked regularly at that interval (in fractional 246 callback will be invoked regularly at that interval (in fractional
229 seconds) after the first invocation. If "interval" is specified with a 247 seconds) after the first invocation. If "interval" is specified with a
230 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.
231 249
232 The callback will be rescheduled before invoking the callback, but no 250 The callback will be rescheduled before invoking the callback, but no
233 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
234 is only approximate. 252 is only approximate.
235 253
236 Example: fire an event after 7.7 seconds. 254 Example: fire an event after 7.7 seconds.
237 255
238 my $w = AnyEvent->timer (after => 7.7, cb => sub { 256 my $w = AnyEvent->timer (after => 7.7, cb => sub {
255 273
256 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,
257 they use absolute time internally. This makes a difference when your 275 they use absolute time internally. This makes a difference when your
258 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
259 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
260 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
261 finally fire. 279 finally fire.
262 280
263 AnyEvent cannot compensate for this. The only event loop that is 281 AnyEvent cannot compensate for this. The only event loop that is
264 conscious about these issues is EV, which offers both relative 282 conscious of these issues is EV, which offers both relative (ev_timer,
265 (ev_timer, based on true relative time) and absolute (ev_periodic, based 283 based on true relative time) and absolute (ev_periodic, based on
266 on wallclock time) timers. 284 wallclock time) timers.
267 285
268 AnyEvent always prefers relative timers, if available, matching the 286 AnyEvent always prefers relative timers, if available, matching the
269 AnyEvent API. 287 AnyEvent API.
270 288
271 AnyEvent has two additional methods that return the "current time": 289 AnyEvent has two additional methods that return the "current time":
290 *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
291 function to call when you want to know the current time.* 309 function to call when you want to know the current time.*
292 310
293 This function is also often faster then "AnyEvent->time", and thus 311 This function is also often faster then "AnyEvent->time", and thus
294 the preferred method if you want some timestamp (for example, 312 the preferred method if you want some timestamp (for example,
295 AnyEvent::Handle uses this to update it's activity timeouts). 313 AnyEvent::Handle uses this to update its activity timeouts).
296 314
297 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
298 exact with your timing, you can skip it without bad conscience. 316 exact with your timing; you can skip it without a bad conscience.
299 317
300 For a practical example of when these times differ, consider 318 For a practical example of when these times differ, consider
301 Event::Lib and EV and the following set-up: 319 Event::Lib and EV and the following set-up:
302 320
303 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
304 at time=500 (assume no other callbacks delay processing). In your 322 at time=500 (assume no other callbacks delay processing). In your
305 callback, you wait a second by executing "sleep 1" (blocking the 323 callback, you wait a second by executing "sleep 1" (blocking the
306 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
307 timer that fires after three seconds. 325 timer that fires after three seconds.
308 326
340 time, which might affect timers and time-outs. 358 time, which might affect timers and time-outs.
341 359
342 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
343 the event loop's idea of "current time". 361 the event loop's idea of "current time".
344 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).
370
345 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.
346 372
347 SIGNAL WATCHERS 373 SIGNAL WATCHERS
374 $w = AnyEvent->signal (signal => <uppercase_signal_name>, cb => <callback>);
375
348 You can watch for signals using a signal watcher, "signal" is the signal 376 You can watch for signals using a signal watcher, "signal" is the signal
349 *name* in uppercase and without any "SIG" prefix, "cb" is the Perl 377 *name* in uppercase and without any "SIG" prefix, "cb" is the Perl
350 callback to be invoked whenever a signal occurs. 378 callback to be invoked whenever a signal occurs.
351 379
352 Although the callback might get passed parameters, their value and 380 Although the callback might get passed parameters, their value and
368 396
369 Example: exit on SIGINT 397 Example: exit on SIGINT
370 398
371 my $w = AnyEvent->signal (signal => "INT", cb => sub { exit 1 }); 399 my $w = AnyEvent->signal (signal => "INT", cb => sub { exit 1 });
372 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
373 Signal Races, Delays and Workarounds 416 Signal Races, Delays and Workarounds
374 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
375 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
376 race-free signal handling in perl. AnyEvent will try to do it's best, 419 race-free signal handling in perl, requiring C libraries for this.
377 but in some cases, signals will be delayed. The maximum time a signal 420 AnyEvent will try to do its best, which means in some cases, signals
378 might be delayed is specified in $AnyEvent::MAX_SIGNAL_LATENCY (default: 421 will be delayed. The maximum time a signal might be delayed is specified
379 10 seconds). This variable can be changed only before the first signal 422 in $AnyEvent::MAX_SIGNAL_LATENCY (default: 10 seconds). This variable
380 watcher is created, and should be left alone otherwise. Higher values 423 can be changed only before the first signal watcher is created, and
424 should be left alone otherwise. This variable determines how often
425 AnyEvent polls for signals (in case a wake-up was missed). Higher values
381 will cause fewer spurious wake-ups, which is better for power and CPU 426 will cause fewer spurious wake-ups, which is better for power and CPU
427 saving.
428
382 saving. All these problems can be avoided by installing the optional 429 All these problems can be avoided by installing the optional
383 Async::Interrupt module. This will not work with inherently broken event 430 Async::Interrupt module, which works with most event loops. It will not
384 loops such as Event or Event::Lib (and not with POE currently, as POE 431 work with inherently broken event loops such as Event or Event::Lib (and
385 does it's own workaround with one-second latency). With those, you just 432 not with POE currently, as POE does its own workaround with one-second
386 have to suffer the delays. 433 latency). For those, you just have to suffer the delays.
387 434
388 CHILD PROCESS WATCHERS 435 CHILD PROCESS WATCHERS
436 $w = AnyEvent->child (pid => <process id>, cb => <callback>);
437
389 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.
390 439
391 The child process is specified by the "pid" argument (if set to 0, it 440 The child process is specified by the "pid" argument (on some backends,
392 watches for any child process exit). The watcher will triggered only 441 using 0 watches for any child process exit, on others this will croak).
393 when the child process has finished and an exit status is available, not 442 The watcher will be triggered only when the child process has finished
394 on any trace events (stopped/continued). 443 and an exit status is available, not on any trace events
444 (stopped/continued).
395 445
396 The callback will be called with the pid and exit status (as returned by 446 The callback will be called with the pid and exit status (as returned by
397 waitpid), so unlike other watcher types, you *can* rely on child watcher 447 waitpid), so unlike other watcher types, you *can* rely on child watcher
398 callback arguments. 448 callback arguments.
399 449
438 488
439 # do something else, then wait for process exit 489 # do something else, then wait for process exit
440 $done->recv; 490 $done->recv;
441 491
442 IDLE WATCHERS 492 IDLE WATCHERS
443 Sometimes there is a need to do something, but it is not so important to 493 $w = AnyEvent->idle (cb => <callback>);
444 do it instantly, but only when there is nothing better to do. This
445 "nothing better to do" is usually defined to be "no other events need
446 attention by the event loop".
447 494
448 Idle watchers ideally get invoked when the event loop has nothing better 495 This will repeatedly invoke the callback after the process becomes idle,
449 to do, just before it would block the process to wait for new events. 496 until either the watcher is destroyed or new events have been detected.
450 Instead of blocking, the idle watcher is invoked.
451 497
452 Most event loops unfortunately do not really support idle watchers (only 498 Idle watchers are useful when there is a need to do something, but it is
499 not so important (or wise) to do it instantly. The callback will be
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.
506
507 Unfortunately, most event loops do not really support idle watchers
453 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,
454 will simply call the callback "from time to time". 509 AnyEvent will simply call the callback "from time to time".
455 510
456 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
457 is otherwise idle: 512 is otherwise idle:
458 513
459 my @lines; # read data 514 my @lines; # read data
472 } 527 }
473 }); 528 });
474 }); 529 });
475 530
476 CONDITION VARIABLES 531 CONDITION VARIABLES
532 $cv = AnyEvent->condvar;
533
534 $cv->send (<list>);
535 my @res = $cv->recv;
536
477 If you are familiar with some event loops you will know that all of them 537 If you are familiar with some event loops you will know that all of them
478 require you to run some blocking "loop", "run" or similar function that 538 require you to run some blocking "loop", "run" or similar function that
479 will actively watch for new events and call your callbacks. 539 will actively watch for new events and call your callbacks.
480 540
481 AnyEvent is slightly different: it expects somebody else to run the 541 AnyEvent is slightly different: it expects somebody else to run the
482 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
483 user). 543 user).
484 544
485 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
486 because they represent a condition that must become true. 546 they represent a condition that must become true.
487 547
488 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.
489 549
490 Condition variables can be created by calling the "AnyEvent->condvar" 550 Condition variables can be created by calling the "AnyEvent->condvar"
491 method, usually without arguments. The only argument pair allowed is 551 method, usually without arguments. The only argument pair allowed is
496 After creation, the condition variable is "false" until it becomes 556 After creation, the condition variable is "false" until it becomes
497 "true" by calling the "send" method (or calling the condition variable 557 "true" by calling the "send" method (or calling the condition variable
498 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
499 the "->send" method). 559 the "->send" method).
500 560
501 Condition variables are similar to callbacks, except that you can 561 Since condition variables are the most complex part of the AnyEvent API,
502 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
503 in time where multiple outstanding events have been processed. And yet 563 you can connect to:
504 another way to call them is transactions - each condition variable can 564
505 be used to represent a transaction, which finishes at some point and 565 * Condition variables are like callbacks - you can call them (and pass
506 delivers a result. And yet some people know them as "futures" - a 566 them instead of callbacks). Unlike callbacks however, you can also
507 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.
508 582
509 Condition variables are very useful to signal that something has 583 Condition variables are very useful to signal that something has
510 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
511 requests, then a condition variable would be the ideal candidate to 585 requests, then a condition variable would be the ideal candidate to
512 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
525 599
526 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
527 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
528 (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
529 AnyEvent). To subclass, use "AnyEvent::CondVar" as base class and call 603 AnyEvent). To subclass, use "AnyEvent::CondVar" as base class and call
530 it's "new" method in your own "new" method. 604 its "new" method in your own "new" method.
531 605
532 There are two "sides" to a condition variable - the "producer side" 606 There are two "sides" to a condition variable - the "producer side"
533 which eventually calls "-> send", and the "consumer side", which waits 607 which eventually calls "-> send", and the "consumer side", which waits
534 for the send to occur. 608 for the send to occur.
535 609
536 Example: wait for a timer. 610 Example: wait for a timer.
537 611
538 # wait till the result is ready 612 # condition: "wait till the timer is fired"
539 my $result_ready = AnyEvent->condvar; 613 my $timer_fired = AnyEvent->condvar;
540 614
541 # do something such as adding a timer 615 # create the timer - we could wait for, say
542 # or socket watcher the calls $result_ready->send 616 # a handle becomign ready, or even an
543 # when the "result" is ready. 617 # AnyEvent::HTTP request to finish, but
544 # in this case, we simply use a timer: 618 # in this case, we simply use a timer:
545 my $w = AnyEvent->timer ( 619 my $w = AnyEvent->timer (
546 after => 1, 620 after => 1,
547 cb => sub { $result_ready->send }, 621 cb => sub { $timer_fired->send },
548 ); 622 );
549 623
550 # this "blocks" (while handling events) till the callback 624 # this "blocks" (while handling events) till the callback
551 # calls -<send 625 # calls ->send
552 $result_ready->recv; 626 $timer_fired->recv;
553 627
554 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
555 variables are also callable directly. 629 variables are also callable directly.
556 630
557 my $done = AnyEvent->condvar; 631 my $done = AnyEvent->condvar;
595 Condition variables are overloaded so one can call them directly (as 669 Condition variables are overloaded so one can call them directly (as
596 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
597 calling "send". 671 calling "send".
598 672
599 $cv->croak ($error) 673 $cv->croak ($error)
600 Similar to send, but causes all call's to "->recv" to invoke 674 Similar to send, but causes all calls to "->recv" to invoke
601 "Carp::croak" with the given error message/object/scalar. 675 "Carp::croak" with the given error message/object/scalar.
602 676
603 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
604 user/consumer. Doing it this way instead of calling "croak" directly 678 user/consumer. Doing it this way instead of calling "croak" directly
605 delays the error detetcion, but has the overwhelmign advantage that 679 delays the error detection, but has the overwhelming advantage that
606 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,
607 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
608 code causing the problem. 682 code causing the problem.
609 683
610 $cv->begin ([group callback]) 684 $cv->begin ([group callback])
611 $cv->end 685 $cv->end
612 These two methods can be used to combine many transactions/events 686 These two methods can be used to combine many transactions/events
613 into one. For example, a function that pings many hosts in parallel 687 into one. For example, a function that pings many hosts in parallel
614 might want to use a condition variable for the whole process. 688 might want to use a condition variable for the whole process.
615 689
616 Every call to "->begin" will increment a counter, and every call to 690 Every call to "->begin" will increment a counter, and every call to
617 "->end" will decrement it. If the counter reaches 0 in "->end", the 691 "->end" will decrement it. If the counter reaches 0 in "->end", the
618 (last) callback passed to "begin" will be executed. That callback is 692 (last) callback passed to "begin" will be executed, passing the
619 *supposed* to call "->send", but that is not required. If no 693 condvar as first argument. That callback is *supposed* to call
694 "->send", but that is not required. If no group callback was set,
620 callback was set, "send" will be called without any arguments. 695 "send" will be called without any arguments.
621 696
622 You can think of "$cv->send" giving you an OR condition (one call 697 You can think of "$cv->send" giving you an OR condition (one call
623 sends), while "$cv->begin" and "$cv->end" giving you an AND 698 sends), while "$cv->begin" and "$cv->end" giving you an AND
624 condition (all "begin" calls must be "end"'ed before the condvar 699 condition (all "begin" calls must be "end"'ed before the condvar
625 sends). 700 sends).
648 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
649 "end" before sending. 724 "end" before sending.
650 725
651 The ping example mentioned above is slightly more complicated, as 726 The ping example mentioned above is slightly more complicated, as
652 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
653 that are begung can potentially be zero: 728 that are begun can potentially be zero:
654 729
655 my $cv = AnyEvent->condvar; 730 my $cv = AnyEvent->condvar;
656 731
657 my %result; 732 my %result;
658 $cv->begin (sub { $cv->send (\%result) }); 733 $cv->begin (sub { shift->send (\%result) });
659 734
660 for my $host (@list_of_hosts) { 735 for my $host (@list_of_hosts) {
661 $cv->begin; 736 $cv->begin;
662 ping_host_then_call_callback $host, sub { 737 ping_host_then_call_callback $host, sub {
663 $result{$host} = ...; 738 $result{$host} = ...;
679 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
680 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
681 (the loop doesn't execute once). 756 (the loop doesn't execute once).
682 757
683 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
684 potentially none) subrequests: use an outer "begin"/"end" pair to 759 potentially zero) subrequests: use an outer "begin"/"end" pair to
685 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,
686 for each subrequest you start, call "begin" and for each subrequest 761 for each subrequest you start, call "begin" and for each subrequest
687 you finish, call "end". 762 you finish, call "end".
688 763
689 METHODS FOR CONSUMERS 764 METHODS FOR CONSUMERS
690 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
691 awaits the condition. 766 awaits the condition.
692 767
693 $cv->recv 768 $cv->recv
694 Wait (blocking if necessary) until the "->send" or "->croak" methods 769 Wait (blocking if necessary) until the "->send" or "->croak" methods
695 have been called on c<$cv>, while servicing other watchers normally. 770 have been called on $cv, while servicing other watchers normally.
696 771
697 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
698 but will return immediately. 773 but will return immediately.
699 774
700 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
717 example, by coupling condition variables with some kind of request 792 example, by coupling condition variables with some kind of request
718 results and supporting callbacks so the caller knows that getting 793 results and supporting callbacks so the caller knows that getting
719 the result will not block, while still supporting blocking waits if 794 the result will not block, while still supporting blocking waits if
720 the caller so desires). 795 the caller so desires).
721 796
722 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
723 only calling "->recv" from within that callback (or at a later 798 only calling "->recv" from within that callback (or at a later
724 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
725 blocking waits otherwise. 800 blocking waits otherwise.
726 801
727 $bool = $cv->ready 802 $bool = $cv->ready
732 This is a mutator function that returns the callback set and 807 This is a mutator function that returns the callback set and
733 optionally replaces it before doing so. 808 optionally replaces it before doing so.
734 809
735 The callback will be called when the condition becomes "true", i.e. 810 The callback will be called when the condition becomes "true", i.e.
736 when "send" or "croak" are called, with the only argument being the 811 when "send" or "croak" are called, with the only argument being the
737 condition variable itself. Calling "recv" inside the callback or at 812 condition variable itself. If the condition is already true, the
813 callback is called immediately when it is set. Calling "recv" inside
738 any later time is guaranteed not to block. 814 the callback or at any later time is guaranteed not to block.
739 815
740SUPPORTED EVENT LOOPS/BACKENDS 816SUPPORTED EVENT LOOPS/BACKENDS
741 The available backend classes are (every class has its own manpage): 817 The available backend classes are (every class has its own manpage):
742 818
743 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.
744 EV is the preferred backend when no other event loop seems to be in 820 EV is the preferred backend when no other event loop seems to be in
745 use. If EV is not installed, then AnyEvent will try Event, and, 821 use. If EV is not installed, then AnyEvent will fall back to its own
746 failing that, will fall back to its own pure-perl implementation, 822 pure-perl implementation, which is available everywhere as it comes
747 which is available everywhere as it comes with AnyEvent itself. 823 with AnyEvent itself.
748 824
749 AnyEvent::Impl::EV based on EV (interface to libev, best choice). 825 AnyEvent::Impl::EV based on EV (interface to libev, best choice).
750 AnyEvent::Impl::Event based on Event, very stable, few glitches.
751 AnyEvent::Impl::Perl pure-perl implementation, fast and portable. 826 AnyEvent::Impl::Perl pure-perl implementation, fast and portable.
752 827
753 Backends that are transparently being picked up when they are used. 828 Backends that are transparently being picked up when they are used.
754 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
755 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
756 is using them. This means that AnyEvent will automatically pick the 831 using them. This means that AnyEvent will automatically pick the
757 right backend when the main program loads an event module before 832 right backend when the main program loads an event module before
758 anything starts to create watchers. Nothing special needs to be done 833 anything starts to create watchers. Nothing special needs to be done
759 by the main program. 834 by the main program.
760 835
836 AnyEvent::Impl::Event based on Event, very stable, few glitches.
761 AnyEvent::Impl::Glib based on Glib, slow but very stable. 837 AnyEvent::Impl::Glib based on Glib, slow but very stable.
762 AnyEvent::Impl::Tk based on Tk, very broken. 838 AnyEvent::Impl::Tk based on Tk, very broken.
763 AnyEvent::Impl::EventLib based on Event::Lib, leaks memory and worse. 839 AnyEvent::Impl::EventLib based on Event::Lib, leaks memory and worse.
764 AnyEvent::Impl::POE based on POE, very slow, some limitations. 840 AnyEvent::Impl::POE based on POE, very slow, some limitations.
841 AnyEvent::Impl::Irssi used when running within irssi.
765 842
766 Backends with special needs. 843 Backends with special needs.
767 Qt requires the Qt::Application to be instantiated first, but will 844 Qt requires the Qt::Application to be instantiated first, but will
768 otherwise be picked up automatically. As long as the main program 845 otherwise be picked up automatically. As long as the main program
769 instantiates the application before any AnyEvent watchers are 846 instantiates the application before any AnyEvent watchers are
773 850
774 Support for IO::Async can only be partial, as it is too broken and 851 Support for IO::Async can only be partial, as it is too broken and
775 architecturally limited to even support the AnyEvent API. It also is 852 architecturally limited to even support the AnyEvent API. It also is
776 the only event loop that needs the loop to be set explicitly, so it 853 the only event loop that needs the loop to be set explicitly, so it
777 can only be used by a main program knowing about AnyEvent. See 854 can only be used by a main program knowing about AnyEvent. See
778 AnyEvent::Impl::Async for the gory details. 855 AnyEvent::Impl::IOAsync for the gory details.
779 856
780 AnyEvent::Impl::IOAsync based on IO::Async, cannot be autoprobed. 857 AnyEvent::Impl::IOAsync based on IO::Async, cannot be autoprobed.
781 858
782 Event loops that are indirectly supported via other backends. 859 Event loops that are indirectly supported via other backends.
783 Some event loops can be supported via other modules: 860 Some event loops can be supported via other modules:
804 Contains "undef" until the first watcher is being created, before 881 Contains "undef" until the first watcher is being created, before
805 the backend has been autodetected. 882 the backend has been autodetected.
806 883
807 Afterwards it contains the event model that is being used, which is 884 Afterwards it contains the event model that is being used, which is
808 the name of the Perl class implementing the model. This class is 885 the name of the Perl class implementing the model. This class is
809 usually one of the "AnyEvent::Impl:xxx" modules, but can be any 886 usually one of the "AnyEvent::Impl::xxx" modules, but can be any
810 other class in the case AnyEvent has been extended at runtime (e.g. 887 other class in the case AnyEvent has been extended at runtime (e.g.
811 in *rxvt-unicode* it will be "urxvt::anyevent"). 888 in *rxvt-unicode* it will be "urxvt::anyevent").
812 889
813 AnyEvent::detect 890 AnyEvent::detect
814 Returns $AnyEvent::MODEL, forcing autodetection of the event model 891 Returns $AnyEvent::MODEL, forcing autodetection of the event model
815 if necessary. You should only call this function right before you 892 if necessary. You should only call this function right before you
816 would have created an AnyEvent watcher anyway, that is, as late as 893 would have created an AnyEvent watcher anyway, that is, as late as
817 possible at runtime, and not e.g. while initialising of your module. 894 possible at runtime, and not e.g. during initialisation of your
895 module.
818 896
819 If you need to do some initialisation before AnyEvent watchers are 897 If you need to do some initialisation before AnyEvent watchers are
820 created, use "post_detect". 898 created, use "post_detect".
821 899
822 $guard = AnyEvent::post_detect { BLOCK } 900 $guard = AnyEvent::post_detect { BLOCK }
823 Arranges for the code block to be executed as soon as the event 901 Arranges for the code block to be executed as soon as the event
824 model is autodetected (or immediately if this has already happened). 902 model is autodetected (or immediately if that has already happened).
825 903
826 The block will be executed *after* the actual backend has been 904 The block will be executed *after* the actual backend has been
827 detected ($AnyEvent::MODEL is set), but *before* any watchers have 905 detected ($AnyEvent::MODEL is set), but *before* any watchers have
828 been created, so it is possible to e.g. patch @AnyEvent::ISA or do 906 been created, so it is possible to e.g. patch @AnyEvent::ISA or do
829 other initialisations - see the sources of AnyEvent::Strict or 907 other initialisations - see the sources of AnyEvent::Strict or
834 creates and installs the global IO::AIO watcher in a "post_detect" 912 creates and installs the global IO::AIO watcher in a "post_detect"
835 block to avoid autodetecting the event module at load time. 913 block to avoid autodetecting the event module at load time.
836 914
837 If called in scalar or list context, then it creates and returns an 915 If called in scalar or list context, then it creates and returns an
838 object that automatically removes the callback again when it is 916 object that automatically removes the callback again when it is
917 destroyed (or "undef" when the hook was immediately executed). See
839 destroyed. See Coro::BDB for a case where this is useful. 918 AnyEvent::AIO for a case where this is useful.
919
920 Example: Create a watcher for the IO::AIO module and store it in
921 $WATCHER, but do so only do so after the event loop is initialised.
922
923 our WATCHER;
924
925 my $guard = AnyEvent::post_detect {
926 $WATCHER = AnyEvent->io (fh => IO::AIO::poll_fileno, poll => 'r', cb => \&IO::AIO::poll_cb);
927 };
928
929 # the ||= is important in case post_detect immediately runs the block,
930 # as to not clobber the newly-created watcher. assigning both watcher and
931 # post_detect guard to the same variable has the advantage of users being
932 # able to just C<undef $WATCHER> if the watcher causes them grief.
933
934 $WATCHER ||= $guard;
840 935
841 @AnyEvent::post_detect 936 @AnyEvent::post_detect
842 If there are any code references in this array (you can "push" to it 937 If there are any code references in this array (you can "push" to it
843 before or after loading AnyEvent), then they will called directly 938 before or after loading AnyEvent), then they will be called directly
844 after the event loop has been chosen. 939 after the event loop has been chosen.
845 940
846 You should check $AnyEvent::MODEL before adding to this array, 941 You should check $AnyEvent::MODEL before adding to this array,
847 though: if it is defined then the event loop has already been 942 though: if it is defined then the event loop has already been
848 detected, and the array will be ignored. 943 detected, and the array will be ignored.
849 944
850 Best use "AnyEvent::post_detect { BLOCK }" when your application 945 Best use "AnyEvent::post_detect { BLOCK }" when your application
851 allows it,as it takes care of these details. 946 allows it, as it takes care of these details.
852 947
853 This variable is mainly useful for modules that can do something 948 This variable is mainly useful for modules that can do something
854 useful when AnyEvent is used and thus want to know when it is 949 useful when AnyEvent is used and thus want to know when it is
855 initialised, but do not need to even load it by default. This array 950 initialised, but do not need to even load it by default. This array
856 provides the means to hook into AnyEvent passively, without loading 951 provides the means to hook into AnyEvent passively, without loading
857 it. 952 it.
858 953
954 Example: To load Coro::AnyEvent whenever Coro and AnyEvent are used
955 together, you could put this into Coro (this is the actual code used
956 by Coro to accomplish this):
957
958 if (defined $AnyEvent::MODEL) {
959 # AnyEvent already initialised, so load Coro::AnyEvent
960 require Coro::AnyEvent;
961 } else {
962 # AnyEvent not yet initialised, so make sure to load Coro::AnyEvent
963 # as soon as it is
964 push @AnyEvent::post_detect, sub { require Coro::AnyEvent };
965 }
966
859WHAT TO DO IN A MODULE 967WHAT TO DO IN A MODULE
860 As a module author, you should "use AnyEvent" and call AnyEvent methods 968 As a module author, you should "use AnyEvent" and call AnyEvent methods
861 freely, but you should not load a specific event module or rely on it. 969 freely, but you should not load a specific event module or rely on it.
862 970
863 Be careful when you create watchers in the module body - AnyEvent will 971 Be careful when you create watchers in the module body - AnyEvent will
870 stall the whole program, and the whole point of using events is to stay 978 stall the whole program, and the whole point of using events is to stay
871 interactive. 979 interactive.
872 980
873 It is fine, however, to call "->recv" when the user of your module 981 It is fine, however, to call "->recv" when the user of your module
874 requests it (i.e. if you create a http request object ad have a method 982 requests it (i.e. if you create a http request object ad have a method
875 called "results" that returns the results, it should call "->recv" 983 called "results" that returns the results, it may call "->recv" freely,
876 freely, as the user of your module knows what she is doing. always). 984 as the user of your module knows what she is doing. Always).
877 985
878WHAT TO DO IN THE MAIN PROGRAM 986WHAT TO DO IN THE MAIN PROGRAM
879 There will always be a single main program - the only place that should 987 There will always be a single main program - the only place that should
880 dictate which event model to use. 988 dictate which event model to use.
881 989
882 If it doesn't care, it can just "use AnyEvent" and use it itself, or not 990 If the program is not event-based, it need not do anything special, even
883 do anything special (it does not need to be event-based) and let 991 when it depends on a module that uses an AnyEvent. If the program itself
884 AnyEvent decide which implementation to chose if some module relies on 992 uses AnyEvent, but does not care which event loop is used, all it needs
885 it. 993 to do is "use AnyEvent". In either case, AnyEvent will choose the best
994 available loop implementation.
886 995
887 If the main program relies on a specific event model - for example, in 996 If the main program relies on a specific event model - for example, in
888 Gtk2 programs you have to rely on the Glib module - you should load the 997 Gtk2 programs you have to rely on the Glib module - you should load the
889 event module before loading AnyEvent or any module that uses it: 998 event module before loading AnyEvent or any module that uses it:
890 generally speaking, you should load it as early as possible. The reason 999 generally speaking, you should load it as early as possible. The reason
891 is that modules might create watchers when they are loaded, and AnyEvent 1000 is that modules might create watchers when they are loaded, and AnyEvent
892 will decide on the event model to use as soon as it creates watchers, 1001 will decide on the event model to use as soon as it creates watchers,
893 and it might chose the wrong one unless you load the correct one 1002 and it might choose the wrong one unless you load the correct one
894 yourself. 1003 yourself.
895 1004
896 You can chose to use a pure-perl implementation by loading the 1005 You can chose to use a pure-perl implementation by loading the
897 "AnyEvent::Impl::Perl" module, which gives you similar behaviour 1006 "AnyEvent::Impl::Perl" module, which gives you similar behaviour
898 everywhere, but letting AnyEvent chose the model is generally better. 1007 everywhere, but letting AnyEvent chose the model is generally better.
915 1024
916OTHER MODULES 1025OTHER MODULES
917 The following is a non-exhaustive list of additional modules that use 1026 The following is a non-exhaustive list of additional modules that use
918 AnyEvent as a client and can therefore be mixed easily with other 1027 AnyEvent as a client and can therefore be mixed easily with other
919 AnyEvent modules and other event loops in the same program. Some of the 1028 AnyEvent modules and other event loops in the same program. Some of the
920 modules come with AnyEvent, most are available via CPAN. 1029 modules come as part of AnyEvent, the others are available via CPAN.
921 1030
922 AnyEvent::Util 1031 AnyEvent::Util
923 Contains various utility functions that replace often-used but 1032 Contains various utility functions that replace often-used blocking
924 blocking functions such as "inet_aton" by event-/callback-based 1033 functions such as "inet_aton" with event/callback-based versions.
925 versions.
926 1034
927 AnyEvent::Socket 1035 AnyEvent::Socket
928 Provides various utility functions for (internet protocol) sockets, 1036 Provides various utility functions for (internet protocol) sockets,
929 addresses and name resolution. Also functions to create non-blocking 1037 addresses and name resolution. Also functions to create non-blocking
930 tcp connections or tcp servers, with IPv6 and SRV record support and 1038 tcp connections or tcp servers, with IPv6 and SRV record support and
931 more. 1039 more.
932 1040
933 AnyEvent::Handle 1041 AnyEvent::Handle
934 Provide read and write buffers, manages watchers for reads and 1042 Provide read and write buffers, manages watchers for reads and
935 writes, supports raw and formatted I/O, I/O queued and fully 1043 writes, supports raw and formatted I/O, I/O queued and fully
936 transparent and non-blocking SSL/TLS (via AnyEvent::TLS. 1044 transparent and non-blocking SSL/TLS (via AnyEvent::TLS).
937 1045
938 AnyEvent::DNS 1046 AnyEvent::DNS
939 Provides rich asynchronous DNS resolver capabilities. 1047 Provides rich asynchronous DNS resolver capabilities.
940 1048
1049 AnyEvent::HTTP, AnyEvent::IRC, AnyEvent::XMPP, AnyEvent::GPSD,
1050 AnyEvent::IGS, AnyEvent::FCP
1051 Implement event-based interfaces to the protocols of the same name
1052 (for the curious, IGS is the International Go Server and FCP is the
1053 Freenet Client Protocol).
1054
1055 AnyEvent::Handle::UDP
1056 Here be danger!
1057
1058 As Pauli would put it, "Not only is it not right, it's not even
1059 wrong!" - there are so many things wrong with AnyEvent::Handle::UDP,
1060 most notably its use of a stream-based API with a protocol that
1061 isn't streamable, that the only way to improve it is to delete it.
1062
1063 It features data corruption (but typically only under load) and
1064 general confusion. On top, the author is not only clueless about UDP
1065 but also fact-resistant - some gems of his understanding: "connect
1066 doesn't work with UDP", "UDP packets are not IP packets", "UDP only
1067 has datagrams, not packets", "I don't need to implement proper error
1068 checking as UDP doesn't support error checking" and so on - he
1069 doesn't even understand what's wrong with his module when it is
1070 explained to him.
1071
941 AnyEvent::HTTP 1072 AnyEvent::DBI
942 A simple-to-use HTTP library that is capable of making a lot of 1073 Executes DBI requests asynchronously in a proxy process for you,
943 concurrent HTTP requests. 1074 notifying you in an event-based way when the operation is finished.
1075
1076 AnyEvent::AIO
1077 Truly asynchronous (as opposed to non-blocking) I/O, should be in
1078 the toolbox of every event programmer. AnyEvent::AIO transparently
1079 fuses IO::AIO and AnyEvent together, giving AnyEvent access to
1080 event-based file I/O, and much more.
944 1081
945 AnyEvent::HTTPD 1082 AnyEvent::HTTPD
946 Provides a simple web application server framework. 1083 A simple embedded webserver.
947 1084
948 AnyEvent::FastPing 1085 AnyEvent::FastPing
949 The fastest ping in the west. 1086 The fastest ping in the west.
950 1087
951 AnyEvent::DBI
952 Executes DBI requests asynchronously in a proxy process.
953
954 AnyEvent::AIO
955 Truly asynchronous I/O, should be in the toolbox of every event
956 programmer. AnyEvent::AIO transparently fuses IO::AIO and AnyEvent
957 together.
958
959 AnyEvent::BDB
960 Truly asynchronous Berkeley DB access. AnyEvent::BDB transparently
961 fuses BDB and AnyEvent together.
962
963 AnyEvent::GPSD
964 A non-blocking interface to gpsd, a daemon delivering GPS
965 information.
966
967 AnyEvent::IRC
968 AnyEvent based IRC client module family (replacing the older
969 Net::IRC3).
970
971 AnyEvent::XMPP
972 AnyEvent based XMPP (Jabber protocol) module family (replacing the
973 older Net::XMPP2>.
974
975 AnyEvent::IGS
976 A non-blocking interface to the Internet Go Server protocol (used by
977 App::IGS).
978
979 Net::FCP
980 AnyEvent-based implementation of the Freenet Client Protocol,
981 birthplace of AnyEvent.
982
983 Event::ExecFlow
984 High level API for event-based execution flow control.
985
986 Coro 1088 Coro
987 Has special support for AnyEvent via Coro::AnyEvent. 1089 Has special support for AnyEvent via Coro::AnyEvent.
1090
1091SIMPLIFIED AE API
1092 Starting with version 5.0, AnyEvent officially supports a second, much
1093 simpler, API that is designed to reduce the calling, typing and memory
1094 overhead by using function call syntax and a fixed number of parameters.
1095
1096 See the AE manpage for details.
988 1097
989ERROR AND EXCEPTION HANDLING 1098ERROR AND EXCEPTION HANDLING
990 In general, AnyEvent does not do any error handling - it relies on the 1099 In general, AnyEvent does not do any error handling - it relies on the
991 caller to do that if required. The AnyEvent::Strict module (see also the 1100 caller to do that if required. The AnyEvent::Strict module (see also the
992 "PERL_ANYEVENT_STRICT" environment variable, below) provides strict 1101 "PERL_ANYEVENT_STRICT" environment variable, below) provides strict
1033 thoroughly check the arguments passed to most method calls. If it 1142 thoroughly check the arguments passed to most method calls. If it
1034 finds any problems, it will croak. 1143 finds any problems, it will croak.
1035 1144
1036 In other words, enables "strict" mode. 1145 In other words, enables "strict" mode.
1037 1146
1038 Unlike "use strict" (or it's modern cousin, "use common::sense", it 1147 Unlike "use strict" (or its modern cousin, "use common::sense", it
1039 is definitely recommended to keep it off in production. Keeping 1148 is definitely recommended to keep it off in production. Keeping
1040 "PERL_ANYEVENT_STRICT=1" in your environment while developing 1149 "PERL_ANYEVENT_STRICT=1" in your environment while developing
1041 programs can be very useful, however. 1150 programs can be very useful, however.
1042 1151
1043 "PERL_ANYEVENT_MODEL" 1152 "PERL_ANYEVENT_MODEL"
1171 warn "read: $input\n"; # output what has been read 1280 warn "read: $input\n"; # output what has been read
1172 $cv->send if $input =~ /^q/i; # quit program if /^q/i 1281 $cv->send if $input =~ /^q/i; # quit program if /^q/i
1173 }, 1282 },
1174 ); 1283 );
1175 1284
1176 my $time_watcher; # can only be used once
1177
1178 sub new_timer {
1179 $timer = AnyEvent->timer (after => 1, cb => sub { 1285 my $time_watcher = AnyEvent->timer (after => 1, interval => 1, cb => sub {
1180 warn "timeout\n"; # print 'timeout' about every second 1286 warn "timeout\n"; # print 'timeout' at most every second
1181 &new_timer; # and restart the time
1182 });
1183 } 1287 });
1184
1185 new_timer; # create first timer
1186 1288
1187 $cv->recv; # wait until user enters /^q/i 1289 $cv->recv; # wait until user enters /^q/i
1188 1290
1189REAL-WORLD EXAMPLE 1291REAL-WORLD EXAMPLE
1190 Consider the Net::FCP module. It features (among others) the following 1292 Consider the Net::FCP module. It features (among others) the following
1262 1364
1263 The actual code goes further and collects all errors ("die"s, 1365 The actual code goes further and collects all errors ("die"s,
1264 exceptions) that occurred during request processing. The "result" method 1366 exceptions) that occurred during request processing. The "result" method
1265 detects whether an exception as thrown (it is stored inside the $txn 1367 detects whether an exception as thrown (it is stored inside the $txn
1266 object) and just throws the exception, which means connection errors and 1368 object) and just throws the exception, which means connection errors and
1267 other problems get reported tot he code that tries to use the result, 1369 other problems get reported to the code that tries to use the result,
1268 not in a random callback. 1370 not in a random callback.
1269 1371
1270 All of this enables the following usage styles: 1372 All of this enables the following usage styles:
1271 1373
1272 1. Blocking: 1374 1. Blocking:
1317 through AnyEvent. The benchmark creates a lot of timers (with a zero 1419 through AnyEvent. The benchmark creates a lot of timers (with a zero
1318 timeout) and I/O watchers (watching STDOUT, a pty, to become writable, 1420 timeout) and I/O watchers (watching STDOUT, a pty, to become writable,
1319 which it is), lets them fire exactly once and destroys them again. 1421 which it is), lets them fire exactly once and destroys them again.
1320 1422
1321 Source code for this benchmark is found as eg/bench in the AnyEvent 1423 Source code for this benchmark is found as eg/bench in the AnyEvent
1322 distribution. 1424 distribution. It uses the AE interface, which makes a real difference
1425 for the EV and Perl backends only.
1323 1426
1324 Explanation of the columns 1427 Explanation of the columns
1325 *watcher* is the number of event watchers created/destroyed. Since 1428 *watcher* is the number of event watchers created/destroyed. Since
1326 different event models feature vastly different performances, each event 1429 different event models feature vastly different performances, each event
1327 loop was given a number of watchers so that overall runtime is 1430 loop was given a number of watchers so that overall runtime is
1346 *destroy* is the time, in microseconds, that it takes to destroy a 1449 *destroy* is the time, in microseconds, that it takes to destroy a
1347 single watcher. 1450 single watcher.
1348 1451
1349 Results 1452 Results
1350 name watchers bytes create invoke destroy comment 1453 name watchers bytes create invoke destroy comment
1351 EV/EV 400000 224 0.47 0.35 0.27 EV native interface 1454 EV/EV 100000 223 0.47 0.43 0.27 EV native interface
1352 EV/Any 100000 224 2.88 0.34 0.27 EV + AnyEvent watchers 1455 EV/Any 100000 223 0.48 0.42 0.26 EV + AnyEvent watchers
1353 CoroEV/Any 100000 224 2.85 0.35 0.28 coroutines + Coro::Signal 1456 Coro::EV/Any 100000 223 0.47 0.42 0.26 coroutines + Coro::Signal
1354 Perl/Any 100000 452 4.13 0.73 0.95 pure perl implementation 1457 Perl/Any 100000 431 2.70 0.74 0.92 pure perl implementation
1355 Event/Event 16000 517 32.20 31.80 0.81 Event native interface 1458 Event/Event 16000 516 31.16 31.84 0.82 Event native interface
1356 Event/Any 16000 590 35.85 31.55 1.06 Event + AnyEvent watchers 1459 Event/Any 16000 1203 42.61 34.79 1.80 Event + AnyEvent watchers
1357 IOAsync/Any 16000 989 38.10 32.77 11.13 via IO::Async::Loop::IO_Poll 1460 IOAsync/Any 16000 1911 41.92 27.45 16.81 via IO::Async::Loop::IO_Poll
1358 IOAsync/Any 16000 990 37.59 29.50 10.61 via IO::Async::Loop::Epoll 1461 IOAsync/Any 16000 1726 40.69 26.37 15.25 via IO::Async::Loop::Epoll
1359 Glib/Any 16000 1357 102.33 12.31 51.00 quadratic behaviour 1462 Glib/Any 16000 1118 89.00 12.57 51.17 quadratic behaviour
1360 Tk/Any 2000 1860 27.20 66.31 14.00 SEGV with >> 2000 watchers 1463 Tk/Any 2000 1346 20.96 10.75 8.00 SEGV with >> 2000 watchers
1361 POE/Event 2000 6328 109.99 751.67 14.02 via POE::Loop::Event 1464 POE/Any 2000 6951 108.97 795.32 14.24 via POE::Loop::Event
1362 POE/Select 2000 6027 94.54 809.13 579.80 via POE::Loop::Select 1465 POE/Any 2000 6648 94.79 774.40 575.51 via POE::Loop::Select
1363 1466
1364 Discussion 1467 Discussion
1365 The benchmark does *not* measure scalability of the event loop very 1468 The benchmark does *not* measure scalability of the event loop very
1366 well. For example, a select-based event loop (such as the pure perl one) 1469 well. For example, a select-based event loop (such as the pure perl one)
1367 can never compete with an event loop that uses epoll when the number of 1470 can never compete with an event loop that uses epoll when the number of
1378 benchmark machine, handling an event takes roughly 1600 CPU cycles with 1481 benchmark machine, handling an event takes roughly 1600 CPU cycles with
1379 EV, 3100 CPU cycles with AnyEvent's pure perl loop and almost 3000000 1482 EV, 3100 CPU cycles with AnyEvent's pure perl loop and almost 3000000
1380 CPU cycles with POE. 1483 CPU cycles with POE.
1381 1484
1382 "EV" is the sole leader regarding speed and memory use, which are both 1485 "EV" is the sole leader regarding speed and memory use, which are both
1383 maximal/minimal, respectively. Even when going through AnyEvent, it uses 1486 maximal/minimal, respectively. When using the AE API there is zero
1487 overhead (when going through the AnyEvent API create is about 5-6 times
1488 slower, with other times being equal, so still uses far less memory than
1384 far less memory than any other event loop and is still faster than Event 1489 any other event loop and is still faster than Event natively).
1385 natively.
1386 1490
1387 The pure perl implementation is hit in a few sweet spots (both the 1491 The pure perl implementation is hit in a few sweet spots (both the
1388 constant timeout and the use of a single fd hit optimisations in the 1492 constant timeout and the use of a single fd hit optimisations in the
1389 perl interpreter and the backend itself). Nevertheless this shows that 1493 perl interpreter and the backend itself). Nevertheless this shows that
1390 it adds very little overhead in itself. Like any select-based backend 1494 it adds very little overhead in itself. Like any select-based backend
1460 In this benchmark, we use 10000 socket pairs (20000 sockets), of which 1564 In this benchmark, we use 10000 socket pairs (20000 sockets), of which
1461 100 (1%) are active. This mirrors the activity of large servers with 1565 100 (1%) are active. This mirrors the activity of large servers with
1462 many connections, most of which are idle at any one point in time. 1566 many connections, most of which are idle at any one point in time.
1463 1567
1464 Source code for this benchmark is found as eg/bench2 in the AnyEvent 1568 Source code for this benchmark is found as eg/bench2 in the AnyEvent
1465 distribution. 1569 distribution. It uses the AE interface, which makes a real difference
1570 for the EV and Perl backends only.
1466 1571
1467 Explanation of the columns 1572 Explanation of the columns
1468 *sockets* is the number of sockets, and twice the number of "servers" 1573 *sockets* is the number of sockets, and twice the number of "servers"
1469 (as each server has a read and write socket end). 1574 (as each server has a read and write socket end).
1470 1575
1476 forwarding it to another server. This includes deleting the old timeout 1581 forwarding it to another server. This includes deleting the old timeout
1477 and creating a new one that moves the timeout into the future. 1582 and creating a new one that moves the timeout into the future.
1478 1583
1479 Results 1584 Results
1480 name sockets create request 1585 name sockets create request
1481 EV 20000 69.01 11.16 1586 EV 20000 62.66 7.99
1482 Perl 20000 73.32 35.87 1587 Perl 20000 68.32 32.64
1483 IOAsync 20000 157.00 98.14 epoll 1588 IOAsync 20000 174.06 101.15 epoll
1484 IOAsync 20000 159.31 616.06 poll 1589 IOAsync 20000 174.67 610.84 poll
1485 Event 20000 212.62 257.32 1590 Event 20000 202.69 242.91
1486 Glib 20000 651.16 1896.30 1591 Glib 20000 557.01 1689.52
1487 POE 20000 349.67 12317.24 uses POE::Loop::Event 1592 POE 20000 341.54 12086.32 uses POE::Loop::Event
1488 1593
1489 Discussion 1594 Discussion
1490 This benchmark *does* measure scalability and overall performance of the 1595 This benchmark *does* measure scalability and overall performance of the
1491 particular event loop. 1596 particular event loop.
1492 1597
1605 As you can see, the AnyEvent + EV combination even beats the 1710 As you can see, the AnyEvent + EV combination even beats the
1606 hand-optimised "raw sockets benchmark", while AnyEvent + its pure perl 1711 hand-optimised "raw sockets benchmark", while AnyEvent + its pure perl
1607 backend easily beats IO::Lambda and POE. 1712 backend easily beats IO::Lambda and POE.
1608 1713
1609 And even the 100% non-blocking version written using the high-level (and 1714 And even the 100% non-blocking version written using the high-level (and
1610 slow :) AnyEvent::Handle abstraction beats both POE and IO::Lambda by a 1715 slow :) AnyEvent::Handle abstraction beats both POE and IO::Lambda
1611 large margin, even though it does all of DNS, tcp-connect and socket I/O 1716 higher level ("unoptimised") abstractions by a large margin, even though
1612 in a non-blocking way. 1717 it does all of DNS, tcp-connect and socket I/O in a non-blocking way.
1613 1718
1614 The two AnyEvent benchmarks programs can be found as eg/ae0.pl and 1719 The two AnyEvent benchmarks programs can be found as eg/ae0.pl and
1615 eg/ae2.pl in the AnyEvent distribution, the remaining benchmarks are 1720 eg/ae2.pl in the AnyEvent distribution, the remaining benchmarks are
1616 part of the IO::lambda distribution and were used without any changes. 1721 part of the IO::Lambda distribution and were used without any changes.
1617 1722
1618SIGNALS 1723SIGNALS
1619 AnyEvent currently installs handlers for these signals: 1724 AnyEvent currently installs handlers for these signals:
1620 1725
1621 SIGCHLD 1726 SIGCHLD
1643 1748
1644 Feel free to install your own handler, or reset it to defaults. 1749 Feel free to install your own handler, or reset it to defaults.
1645 1750
1646RECOMMENDED/OPTIONAL MODULES 1751RECOMMENDED/OPTIONAL MODULES
1647 One of AnyEvent's main goals is to be 100% Pure-Perl(tm): only perl (and 1752 One of AnyEvent's main goals is to be 100% Pure-Perl(tm): only perl (and
1648 it's built-in modules) are required to use it. 1753 its built-in modules) are required to use it.
1649 1754
1650 That does not mean that AnyEvent won't take advantage of some additional 1755 That does not mean that AnyEvent won't take advantage of some additional
1651 modules if they are installed. 1756 modules if they are installed.
1652 1757
1653 This section epxlains which additional modules will be used, and how 1758 This section explains which additional modules will be used, and how
1654 they affect AnyEvent's operetion. 1759 they affect AnyEvent's operation.
1655 1760
1656 Async::Interrupt 1761 Async::Interrupt
1657 This slightly arcane module is used to implement fast signal 1762 This slightly arcane module is used to implement fast signal
1658 handling: To my knowledge, there is no way to do completely 1763 handling: To my knowledge, there is no way to do completely
1659 race-free and quick signal handling in pure perl. To ensure that 1764 race-free and quick signal handling in pure perl. To ensure that
1662 10 seconds, look for $AnyEvent::MAX_SIGNAL_LATENCY). 1767 10 seconds, look for $AnyEvent::MAX_SIGNAL_LATENCY).
1663 1768
1664 If this module is available, then it will be used to implement 1769 If this module is available, then it will be used to implement
1665 signal catching, which means that signals will not be delayed, and 1770 signal catching, which means that signals will not be delayed, and
1666 the event loop will not be interrupted regularly, which is more 1771 the event loop will not be interrupted regularly, which is more
1667 efficient (And good for battery life on laptops). 1772 efficient (and good for battery life on laptops).
1668 1773
1669 This affects not just the pure-perl event loop, but also other event 1774 This affects not just the pure-perl event loop, but also other event
1670 loops that have no signal handling on their own (e.g. Glib, Tk, Qt). 1775 loops that have no signal handling on their own (e.g. Glib, Tk, Qt).
1671 1776
1672 Some event loops (POE, Event, Event::Lib) offer signal watchers 1777 Some event loops (POE, Event, Event::Lib) offer signal watchers
1682 clock is available, can take avdantage of advanced kernel interfaces 1787 clock is available, can take avdantage of advanced kernel interfaces
1683 such as "epoll" and "kqueue", and is the fastest backend *by far*. 1788 such as "epoll" and "kqueue", and is the fastest backend *by far*.
1684 You can even embed Glib/Gtk2 in it (or vice versa, see EV::Glib and 1789 You can even embed Glib/Gtk2 in it (or vice versa, see EV::Glib and
1685 Glib::EV). 1790 Glib::EV).
1686 1791
1792 If you only use backends that rely on another event loop (e.g.
1793 "Tk"), then this module will do nothing for you.
1794
1687 Guard 1795 Guard
1688 The guard module, when used, will be used to implement 1796 The guard module, when used, will be used to implement
1689 "AnyEvent::Util::guard". This speeds up guards considerably (and 1797 "AnyEvent::Util::guard". This speeds up guards considerably (and
1690 uses a lot less memory), but otherwise doesn't affect guard 1798 uses a lot less memory), but otherwise doesn't affect guard
1691 operation much. It is purely used for performance. 1799 operation much. It is purely used for performance.
1692 1800
1693 JSON and JSON::XS 1801 JSON and JSON::XS
1694 This module is required when you want to read or write JSON data via 1802 One of these modules is required when you want to read or write JSON
1695 AnyEvent::Handle. It is also written in pure-perl, but can take 1803 data via AnyEvent::Handle. JSON is also written in pure-perl, but
1696 advantage of the ultra-high-speed JSON::XS module when it is 1804 can take advantage of the ultra-high-speed JSON::XS module when it
1697 installed. 1805 is installed.
1698
1699 In fact, AnyEvent::Handle will use JSON::XS by default if it is
1700 installed.
1701 1806
1702 Net::SSLeay 1807 Net::SSLeay
1703 Implementing TLS/SSL in Perl is certainly interesting, but not very 1808 Implementing TLS/SSL in Perl is certainly interesting, but not very
1704 worthwhile: If this module is installed, then AnyEvent::Handle (with 1809 worthwhile: If this module is installed, then AnyEvent::Handle (with
1705 the help of AnyEvent::TLS), gains the ability to do TLS/SSL. 1810 the help of AnyEvent::TLS), gains the ability to do TLS/SSL.
1706 1811
1707 Time::HiRes 1812 Time::HiRes
1708 This module is part of perl since release 5.008. It will be used 1813 This module is part of perl since release 5.008. It will be used
1709 when the chosen event library does not come with a timing source on 1814 when the chosen event library does not come with a timing source of
1710 it's own. The pure-perl event loop (AnyEvent::Impl::Perl) will 1815 its own. The pure-perl event loop (AnyEvent::Impl::Perl) will
1711 additionally use it to try to use a monotonic clock for timing 1816 additionally use it to try to use a monotonic clock for timing
1712 stability. 1817 stability.
1713 1818
1714FORK 1819FORK
1715 Most event libraries are not fork-safe. The ones who are usually are 1820 Most event libraries are not fork-safe. The ones who are usually are
1716 because they rely on inefficient but fork-safe "select" or "poll" calls. 1821 because they rely on inefficient but fork-safe "select" or "poll" calls
1717 Only EV is fully fork-aware. 1822 - higher performance APIs such as BSD's kqueue or the dreaded Linux
1823 epoll are usually badly thought-out hacks that are incompatible with
1824 fork in one way or another. Only EV is fully fork-aware and ensures that
1825 you continue event-processing in both parent and child (or both, if you
1826 know what you are doing).
1827
1828 This means that, in general, you cannot fork and do event processing in
1829 the child if the event library was initialised before the fork (which
1830 usually happens when the first AnyEvent watcher is created, or the
1831 library is loaded).
1718 1832
1719 If you have to fork, you must either do so *before* creating your first 1833 If you have to fork, you must either do so *before* creating your first
1720 watcher OR you must not use AnyEvent at all in the child OR you must do 1834 watcher OR you must not use AnyEvent at all in the child OR you must do
1721 something completely out of the scope of AnyEvent. 1835 something completely out of the scope of AnyEvent.
1836
1837 The problem of doing event processing in the parent *and* the child is
1838 much more complicated: even for backends that *are* fork-aware or
1839 fork-safe, their behaviour is not usually what you want: fork clones all
1840 watchers, that means all timers, I/O watchers etc. are active in both
1841 parent and child, which is almost never what you want. USing "exec" to
1842 start worker children from some kind of manage rprocess is usually
1843 preferred, because it is much easier and cleaner, at the expense of
1844 having to have another binary.
1722 1845
1723SECURITY CONSIDERATIONS 1846SECURITY CONSIDERATIONS
1724 AnyEvent can be forced to load any event model via 1847 AnyEvent can be forced to load any event model via
1725 $ENV{PERL_ANYEVENT_MODEL}. While this cannot (to my knowledge) be used 1848 $ENV{PERL_ANYEVENT_MODEL}. While this cannot (to my knowledge) be used
1726 to execute arbitrary code or directly gain access, it can easily be used 1849 to execute arbitrary code or directly gain access, it can easily be used
1750 5.10 and check wether the leaks still show up. (Perl 5.10.0 has other 1873 5.10 and check wether the leaks still show up. (Perl 5.10.0 has other
1751 annoying memleaks, such as leaking on "map" and "grep" but it is usually 1874 annoying memleaks, such as leaking on "map" and "grep" but it is usually
1752 not as pronounced). 1875 not as pronounced).
1753 1876
1754SEE ALSO 1877SEE ALSO
1878 Tutorial/Introduction: AnyEvent::Intro.
1879
1880 FAQ: AnyEvent::FAQ.
1881
1755 Utility functions: AnyEvent::Util. 1882 Utility functions: AnyEvent::Util.
1756 1883
1757 Event modules: EV, EV::Glib, Glib::EV, Event, Glib::Event, Glib, Tk, 1884 Event modules: EV, EV::Glib, Glib::EV, Event, Glib::Event, Glib, Tk,
1758 Event::Lib, Qt, POE. 1885 Event::Lib, Qt, POE.
1759 1886
1760 Implementations: AnyEvent::Impl::EV, AnyEvent::Impl::Event, 1887 Implementations: AnyEvent::Impl::EV, AnyEvent::Impl::Event,
1761 AnyEvent::Impl::Glib, AnyEvent::Impl::Tk, AnyEvent::Impl::Perl, 1888 AnyEvent::Impl::Glib, AnyEvent::Impl::Tk, AnyEvent::Impl::Perl,
1762 AnyEvent::Impl::EventLib, AnyEvent::Impl::Qt, AnyEvent::Impl::POE, 1889 AnyEvent::Impl::EventLib, AnyEvent::Impl::Qt, AnyEvent::Impl::POE,
1763 AnyEvent::Impl::IOAsync. 1890 AnyEvent::Impl::IOAsync, Anyevent::Impl::Irssi.
1764 1891
1765 Non-blocking file handles, sockets, TCP clients and servers: 1892 Non-blocking file handles, sockets, TCP clients and servers:
1766 AnyEvent::Handle, AnyEvent::Socket, AnyEvent::TLS. 1893 AnyEvent::Handle, AnyEvent::Socket, AnyEvent::TLS.
1767 1894
1768 Asynchronous DNS: AnyEvent::DNS. 1895 Asynchronous DNS: AnyEvent::DNS.
1769 1896
1770 Coroutine support: Coro, Coro::AnyEvent, Coro::EV, Coro::Event, 1897 Thread support: Coro, Coro::AnyEvent, Coro::EV, Coro::Event.
1771 1898
1772 Nontrivial usage examples: AnyEvent::GPSD, AnyEvent::XMPP, 1899 Nontrivial usage examples: AnyEvent::GPSD, AnyEvent::IRC,
1773 AnyEvent::HTTP. 1900 AnyEvent::HTTP.
1774 1901
1775AUTHOR 1902AUTHOR
1776 Marc Lehmann <schmorp@schmorp.de> 1903 Marc Lehmann <schmorp@schmorp.de>
1777 http://home.schmorp.de/ 1904 http://home.schmorp.de/

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines