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

Comparing AnyEvent/README (file contents):
Revision 1.46 by root, Sat Jul 18 05:19:09 2009 UTC vs.
Revision 1.64 by root, Fri Dec 31 04:50:44 2010 UTC

1NAME 1NAME
2 AnyEvent - provide framework for multiple event loops 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
37 40
38INTRODUCTION/TUTORIAL 41INTRODUCTION/TUTORIAL
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.
45
46SUPPORT
47 An FAQ document is available as AnyEvent::FAQ.
48
49 There also is a mailinglist for discussing all things AnyEvent, and an
50 IRC channel, too.
51
52 See the AnyEvent project page at the Schmorpforge Ta-Sa Software
53 Repository, at <http://anyevent.schmorp.de>, for more info.
42 54
43WHY YOU SHOULD USE THIS MODULE (OR NOT) 55WHY YOU SHOULD USE THIS MODULE (OR NOT)
44 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
45 nowadays. So what is different about AnyEvent? 57 nowadays. So what is different about AnyEvent?
46 58
61 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
62 model you use. 74 model you use.
63 75
64 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
65 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
66 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
67 cannot use anything else, as they are simply incompatible to everything 79 cannot use anything else, as they are simply incompatible to everything
68 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
69 are *also* forced to use the same event loop you use. 81 are *also* forced to use the same event loop you use.
70 82
71 AnyEvent is different: AnyEvent + POE works fine. AnyEvent + Glib works 83 AnyEvent is different: AnyEvent + POE works fine. AnyEvent + Glib works
72 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
73 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
74 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
75 But if your module uses AnyEvent, it works transparently with all event 87 your module uses AnyEvent, it works transparently with all event models
76 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
77 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
78 to AnyEvent, too, so it is future-proof). 90 AnyEvent, too, so it is future-proof).
79 91
80 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
81 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
82 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
83 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
84 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
85 wrapper as technically possible. 97 technically possible.
86 98
87 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
88 useful functionality, such as an asynchronous DNS resolver, 100% 100 useful functionality, such as an asynchronous DNS resolver, 100%
89 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
90 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
93 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
94 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
95 model, you should *not* use this module. 107 model, you should *not* use this module.
96 108
97DESCRIPTION 109DESCRIPTION
98 AnyEvent provides an identical interface to multiple event loops. This 110 AnyEvent provides a uniform interface to various event loops. This
99 allows module authors to utilise an event loop without forcing module 111 allows module authors to use event loop functionality without forcing
100 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
101 coexist peacefully at any one time). 113 than one event loop cannot coexist peacefully).
102 114
103 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
104 module. 116 module.
105 117
106 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
107 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
108 following modules is already loaded: EV, Event, Glib, 120 following modules is already loaded: EV, AnyEvent::Impl::Perl, Event,
109 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
110 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
111 (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
112 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
113 successfully loaded will be used. If, after this, still none could be 125 normally tried.
114 found, AnyEvent will fall back to a pure-perl event loop, which is not
115 very efficient, but should work everywhere.
116 126
117 Because AnyEvent first checks for modules that are already loaded, 127 Because AnyEvent first checks for modules that are already loaded,
118 loading an event model explicitly before first using AnyEvent will 128 loading an event model explicitly before first using AnyEvent will
119 likely make that model the default. For example: 129 likely make that model the default. For example:
120 130
122 use AnyEvent; 132 use AnyEvent;
123 133
124 # .. AnyEvent will likely default to Tk 134 # .. AnyEvent will likely default to Tk
125 135
126 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
127 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
128 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.
129 140
130 The pure-perl implementation of AnyEvent is called 141 The pure-perl implementation of AnyEvent is called
131 "AnyEvent::Impl::Perl". Like other event modules you can load it 142 "AnyEvent::Impl::Perl". Like other event modules you can load it
132 explicitly and enjoy the high availability of that event loop :) 143 explicitly and enjoy the high availability of that event loop :)
133 144
141 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
142 in control). 153 in control).
143 154
144 Note that callbacks must not permanently change global variables 155 Note that callbacks must not permanently change global variables
145 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
146 callbacks must not "die". The former is good programming practise in 157 callbacks must not "die". The former is good programming practice in
147 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
148 widely between event loops. 159 widely between event loops.
149 160
150 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
151 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
152 to it). 163 to it).
153 164
154 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.
155 166
156 Many watchers either are used with "recursion" (repeating timers for 167 Many watchers either are used with "recursion" (repeating timers for
157 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.
158 169
159 An any way to achieve that is this pattern: 170 One way to achieve that is this pattern:
160 171
161 my $w; $w = AnyEvent->type (arg => value ..., cb => sub { 172 my $w; $w = AnyEvent->type (arg => value ..., cb => sub {
162 # you can use $w here, for example to undef it 173 # you can use $w here, for example to undef it
163 undef $w; 174 undef $w;
164 }); 175 });
166 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,
167 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
168 declared. 179 declared.
169 180
170 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
171 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
172 the following mandatory key-value pairs as arguments: 189 the following mandatory key-value pairs as arguments:
173 190
174 "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
175 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
189 206
190 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
191 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
192 the underlying file descriptor. 209 the underlying file descriptor.
193 210
194 Some event loops issue spurious readyness notifications, so you should 211 Some event loops issue spurious readiness notifications, so you should
195 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
196 handles. 213 handles.
197 214
198 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
199 watcher. 216 watcher.
203 warn "read: $input\n"; 220 warn "read: $input\n";
204 undef $w; 221 undef $w;
205 }); 222 });
206 223
207 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
208 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
209 with the following mandatory arguments: 234 with the following mandatory arguments:
210 235
211 "after" specifies after how many seconds (fractional values are 236 "after" specifies after how many seconds (fractional values are
212 supported) the callback should be invoked. "cb" is the callback to 237 supported) the callback should be invoked. "cb" is the callback to
214 239
215 Although the callback might get passed parameters, their value and 240 Although the callback might get passed parameters, their value and
216 presence is undefined and you cannot rely on them. Portable AnyEvent 241 presence is undefined and you cannot rely on them. Portable AnyEvent
217 callbacks cannot use arguments passed to time watcher callbacks. 242 callbacks cannot use arguments passed to time watcher callbacks.
218 243
219 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
220 parameter, "interval", as a strictly positive number (> 0), then the 245 parameter, "interval", as a strictly positive number (> 0), then the
221 callback will be invoked regularly at that interval (in fractional 246 callback will be invoked regularly at that interval (in fractional
222 seconds) after the first invocation. If "interval" is specified with a 247 seconds) after the first invocation. If "interval" is specified with a
223 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.
224 249
225 The callback will be rescheduled before invoking the callback, but no 250 The callback will be rescheduled before invoking the callback, but no
226 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
227 is only approximate. 252 is only approximate.
228 253
229 Example: fire an event after 7.7 seconds. 254 Example: fire an event after 7.7 seconds.
230 255
231 my $w = AnyEvent->timer (after => 7.7, cb => sub { 256 my $w = AnyEvent->timer (after => 7.7, cb => sub {
248 273
249 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,
250 they use absolute time internally. This makes a difference when your 275 they use absolute time internally. This makes a difference when your
251 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
252 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
253 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
254 finally fire. 279 finally fire.
255 280
256 AnyEvent cannot compensate for this. The only event loop that is 281 AnyEvent cannot compensate for this. The only event loop that is
257 conscious about these issues is EV, which offers both relative 282 conscious of these issues is EV, which offers both relative (ev_timer,
258 (ev_timer, based on true relative time) and absolute (ev_periodic, based 283 based on true relative time) and absolute (ev_periodic, based on
259 on wallclock time) timers. 284 wallclock time) timers.
260 285
261 AnyEvent always prefers relative timers, if available, matching the 286 AnyEvent always prefers relative timers, if available, matching the
262 AnyEvent API. 287 AnyEvent API.
263 288
264 AnyEvent has two additional methods that return the "current time": 289 AnyEvent has two additional methods that return the "current time":
283 *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
284 function to call when you want to know the current time.* 309 function to call when you want to know the current time.*
285 310
286 This function is also often faster then "AnyEvent->time", and thus 311 This function is also often faster then "AnyEvent->time", and thus
287 the preferred method if you want some timestamp (for example, 312 the preferred method if you want some timestamp (for example,
288 AnyEvent::Handle uses this to update it's activity timeouts). 313 AnyEvent::Handle uses this to update its activity timeouts).
289 314
290 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
291 exact with your timing, you can skip it without bad conscience. 316 exact with your timing; you can skip it without a bad conscience.
292 317
293 For a practical example of when these times differ, consider 318 For a practical example of when these times differ, consider
294 Event::Lib and EV and the following set-up: 319 Event::Lib and EV and the following set-up:
295 320
296 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
297 at time=500 (assume no other callbacks delay processing). In your 322 at time=500 (assume no other callbacks delay processing). In your
298 callback, you wait a second by executing "sleep 1" (blocking the 323 callback, you wait a second by executing "sleep 1" (blocking the
299 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
300 timer that fires after three seconds. 325 timer that fires after three seconds.
301 326
333 time, which might affect timers and time-outs. 358 time, which might affect timers and time-outs.
334 359
335 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
336 the event loop's idea of "current time". 361 the event loop's idea of "current time".
337 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
338 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.
339 372
340 SIGNAL WATCHERS 373 SIGNAL WATCHERS
374 $w = AnyEvent->signal (signal => <uppercase_signal_name>, cb => <callback>);
375
341 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
342 *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
343 callback to be invoked whenever a signal occurs. 378 callback to be invoked whenever a signal occurs.
344 379
345 Although the callback might get passed parameters, their value and 380 Although the callback might get passed parameters, their value and
357 392
358 This watcher might use %SIG (depending on the event loop used), so 393 This watcher might use %SIG (depending on the event loop used), so
359 programs overwriting those signals directly will likely not work 394 programs overwriting those signals directly will likely not work
360 correctly. 395 correctly.
361 396
397 Example: exit on SIGINT
398
399 my $w = AnyEvent->signal (signal => "INT", cb => sub { exit 1 });
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
416 Signal Races, Delays and Workarounds
362 Also note that many event loops (e.g. Glib, Tk, Qt, IO::Async) do not 417 Many event loops (e.g. Glib, Tk, Qt, IO::Async) do not support attaching
363 support attaching callbacks to signals, which is a pity, as you cannot 418 callbacks to signals in a generic way, which is a pity, as you cannot do
364 do 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.
365 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
366 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
367 10 seconds). This variable can be changed only before the first signal 422 in $AnyEvent::MAX_SIGNAL_LATENCY (default: 10 seconds). This variable
368 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
369 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
370 saving. All these problems can be avoided by installing the optional 429 All these problems can be avoided by installing the optional
371 Async::Interrupt module. 430 Async::Interrupt module, which works with most event loops. It will not
372 431 work with inherently broken event loops such as Event or Event::Lib (and
373 Example: exit on SIGINT 432 not with POE currently, as POE does its own workaround with one-second
374 433 latency). For those, you just have to suffer the delays.
375 my $w = AnyEvent->signal (signal => "INT", cb => sub { exit 1 });
376 434
377 CHILD PROCESS WATCHERS 435 CHILD PROCESS WATCHERS
436 $w = AnyEvent->child (pid => <process id>, cb => <callback>);
437
378 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.
379 439
380 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,
381 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).
382 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
383 on any trace events (stopped/continued). 443 and an exit status is available, not on any trace events
444 (stopped/continued).
384 445
385 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
386 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
387 callback arguments. 448 callback arguments.
388 449
427 488
428 # do something else, then wait for process exit 489 # do something else, then wait for process exit
429 $done->recv; 490 $done->recv;
430 491
431 IDLE WATCHERS 492 IDLE WATCHERS
432 Sometimes there is a need to do something, but it is not so important to 493 $w = AnyEvent->idle (cb => <callback>);
433 do it instantly, but only when there is nothing better to do. This
434 "nothing better to do" is usually defined to be "no other events need
435 attention by the event loop".
436 494
437 Idle watchers ideally get invoked when the event loop has nothing better 495 This will repeatedly invoke the callback after the process becomes idle,
438 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.
439 Instead of blocking, the idle watcher is invoked.
440 497
441 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
442 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,
443 will simply call the callback "from time to time". 509 AnyEvent will simply call the callback "from time to time".
444 510
445 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
446 is otherwise idle: 512 is otherwise idle:
447 513
448 my @lines; # read data 514 my @lines; # read data
461 } 527 }
462 }); 528 });
463 }); 529 });
464 530
465 CONDITION VARIABLES 531 CONDITION VARIABLES
532 $cv = AnyEvent->condvar;
533
534 $cv->send (<list>);
535 my @res = $cv->recv;
536
466 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
467 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
468 will actively watch for new events and call your callbacks. 539 will actively watch for new events and call your callbacks.
469 540
470 AnyEvent is slightly different: it expects somebody else to run the 541 AnyEvent is slightly different: it expects somebody else to run the
471 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
472 user). 543 user).
473 544
474 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
475 because they represent a condition that must become true. 546 they represent a condition that must become true.
476 547
477 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.
478 549
479 Condition variables can be created by calling the "AnyEvent->condvar" 550 Condition variables can be created by calling the "AnyEvent->condvar"
480 method, usually without arguments. The only argument pair allowed is 551 method, usually without arguments. The only argument pair allowed is
485 After creation, the condition variable is "false" until it becomes 556 After creation, the condition variable is "false" until it becomes
486 "true" by calling the "send" method (or calling the condition variable 557 "true" by calling the "send" method (or calling the condition variable
487 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
488 the "->send" method). 559 the "->send" method).
489 560
490 Condition variables are similar to callbacks, except that you can 561 Since condition variables are the most complex part of the AnyEvent API,
491 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
492 in time where multiple outstanding events have been processed. And yet 563 you can connect to:
493 another way to call them is transactions - each condition variable can 564
494 be used to represent a transaction, which finishes at some point and 565 * Condition variables are like callbacks - you can call them (and pass
495 delivers a result. 566 them instead of callbacks). Unlike callbacks however, you can also
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.
496 582
497 Condition variables are very useful to signal that something has 583 Condition variables are very useful to signal that something has
498 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
499 requests, then a condition variable would be the ideal candidate to 585 requests, then a condition variable would be the ideal candidate to
500 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
513 599
514 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
515 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
516 (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
517 AnyEvent). To subclass, use "AnyEvent::CondVar" as base class and call 603 AnyEvent). To subclass, use "AnyEvent::CondVar" as base class and call
518 it's "new" method in your own "new" method. 604 its "new" method in your own "new" method.
519 605
520 There are two "sides" to a condition variable - the "producer side" 606 There are two "sides" to a condition variable - the "producer side"
521 which eventually calls "-> send", and the "consumer side", which waits 607 which eventually calls "-> send", and the "consumer side", which waits
522 for the send to occur. 608 for the send to occur.
523 609
524 Example: wait for a timer. 610 Example: wait for a timer.
525 611
526 # wait till the result is ready 612 # condition: "wait till the timer is fired"
527 my $result_ready = AnyEvent->condvar; 613 my $timer_fired = AnyEvent->condvar;
528 614
529 # do something such as adding a timer 615 # create the timer - we could wait for, say
530 # or socket watcher the calls $result_ready->send 616 # a handle becomign ready, or even an
531 # when the "result" is ready. 617 # AnyEvent::HTTP request to finish, but
532 # in this case, we simply use a timer: 618 # in this case, we simply use a timer:
533 my $w = AnyEvent->timer ( 619 my $w = AnyEvent->timer (
534 after => 1, 620 after => 1,
535 cb => sub { $result_ready->send }, 621 cb => sub { $timer_fired->send },
536 ); 622 );
537 623
538 # this "blocks" (while handling events) till the callback 624 # this "blocks" (while handling events) till the callback
539 # calls -<send 625 # calls ->send
540 $result_ready->recv; 626 $timer_fired->recv;
541 627
542 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
543 variables are also callable directly. 629 variables are also callable directly.
544 630
545 my $done = AnyEvent->condvar; 631 my $done = AnyEvent->condvar;
583 Condition variables are overloaded so one can call them directly (as 669 Condition variables are overloaded so one can call them directly (as
584 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
585 calling "send". 671 calling "send".
586 672
587 $cv->croak ($error) 673 $cv->croak ($error)
588 Similar to send, but causes all call's to "->recv" to invoke 674 Similar to send, but causes all calls to "->recv" to invoke
589 "Carp::croak" with the given error message/object/scalar. 675 "Carp::croak" with the given error message/object/scalar.
590 676
591 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
592 user/consumer. Doing it this way instead of calling "croak" directly 678 user/consumer. Doing it this way instead of calling "croak" directly
593 delays the error detetcion, but has the overwhelmign advantage that 679 delays the error detection, but has the overwhelming advantage that
594 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,
595 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
596 code causing the problem. 682 code causing the problem.
597 683
598 $cv->begin ([group callback]) 684 $cv->begin ([group callback])
599 $cv->end 685 $cv->end
600 These two methods can be used to combine many transactions/events 686 These two methods can be used to combine many transactions/events
601 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
602 might want to use a condition variable for the whole process. 688 might want to use a condition variable for the whole process.
603 689
604 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
605 "->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
606 (last) callback passed to "begin" will be executed. That callback is 692 (last) callback passed to "begin" will be executed, passing the
607 *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,
608 callback was set, "send" will be called without any arguments. 695 "send" will be called without any arguments.
609 696
610 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
611 sends), while "$cv->begin" and "$cv->end" giving you an AND 698 sends), while "$cv->begin" and "$cv->end" giving you an AND
612 condition (all "begin" calls must be "end"'ed before the condvar 699 condition (all "begin" calls must be "end"'ed before the condvar
613 sends). 700 sends).
636 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
637 "end" before sending. 724 "end" before sending.
638 725
639 The ping example mentioned above is slightly more complicated, as 726 The ping example mentioned above is slightly more complicated, as
640 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
641 that are begung can potentially be zero: 728 that are begun can potentially be zero:
642 729
643 my $cv = AnyEvent->condvar; 730 my $cv = AnyEvent->condvar;
644 731
645 my %result; 732 my %result;
646 $cv->begin (sub { $cv->send (\%result) }); 733 $cv->begin (sub { shift->send (\%result) });
647 734
648 for my $host (@list_of_hosts) { 735 for my $host (@list_of_hosts) {
649 $cv->begin; 736 $cv->begin;
650 ping_host_then_call_callback $host, sub { 737 ping_host_then_call_callback $host, sub {
651 $result{$host} = ...; 738 $result{$host} = ...;
667 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
668 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
669 (the loop doesn't execute once). 756 (the loop doesn't execute once).
670 757
671 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
672 potentially none) subrequests: use an outer "begin"/"end" pair to 759 potentially zero) subrequests: use an outer "begin"/"end" pair to
673 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,
674 for each subrequest you start, call "begin" and for each subrequest 761 for each subrequest you start, call "begin" and for each subrequest
675 you finish, call "end". 762 you finish, call "end".
676 763
677 METHODS FOR CONSUMERS 764 METHODS FOR CONSUMERS
678 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
679 awaits the condition. 766 awaits the condition.
680 767
681 $cv->recv 768 $cv->recv
682 Wait (blocking if necessary) until the "->send" or "->croak" methods 769 Wait (blocking if necessary) until the "->send" or "->croak" methods
683 have been called on c<$cv>, while servicing other watchers normally. 770 have been called on $cv, while servicing other watchers normally.
684 771
685 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
686 but will return immediately. 773 but will return immediately.
687 774
688 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
705 example, by coupling condition variables with some kind of request 792 example, by coupling condition variables with some kind of request
706 results and supporting callbacks so the caller knows that getting 793 results and supporting callbacks so the caller knows that getting
707 the result will not block, while still supporting blocking waits if 794 the result will not block, while still supporting blocking waits if
708 the caller so desires). 795 the caller so desires).
709 796
710 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
711 only calling "->recv" from within that callback (or at a later 798 only calling "->recv" from within that callback (or at a later
712 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
713 blocking waits otherwise. 800 blocking waits otherwise.
714 801
715 $bool = $cv->ready 802 $bool = $cv->ready
720 This is a mutator function that returns the callback set and 807 This is a mutator function that returns the callback set and
721 optionally replaces it before doing so. 808 optionally replaces it before doing so.
722 809
723 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.
724 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
725 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
726 any later time is guaranteed not to block. 814 the callback or at any later time is guaranteed not to block.
727 815
728SUPPORTED EVENT LOOPS/BACKENDS 816SUPPORTED EVENT LOOPS/BACKENDS
729 The available backend classes are (every class has its own manpage): 817 The available backend classes are (every class has its own manpage):
730 818
731 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.
732 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
733 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
734 failing that, will fall back to its own pure-perl implementation, 822 pure-perl implementation, which is available everywhere as it comes
735 which is available everywhere as it comes with AnyEvent itself. 823 with AnyEvent itself.
736 824
737 AnyEvent::Impl::EV based on EV (interface to libev, best choice). 825 AnyEvent::Impl::EV based on EV (interface to libev, best choice).
738 AnyEvent::Impl::Event based on Event, very stable, few glitches.
739 AnyEvent::Impl::Perl pure-perl implementation, fast and portable. 826 AnyEvent::Impl::Perl pure-perl implementation, fast and portable.
740 827
741 Backends that are transparently being picked up when they are used. 828 Backends that are transparently being picked up when they are used.
742 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
743 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
744 is using them. This means that AnyEvent will automatically pick the 831 using them. This means that AnyEvent will automatically pick the
745 right backend when the main program loads an event module before 832 right backend when the main program loads an event module before
746 anything starts to create watchers. Nothing special needs to be done 833 anything starts to create watchers. Nothing special needs to be done
747 by the main program. 834 by the main program.
748 835
836 AnyEvent::Impl::Event based on Event, very stable, few glitches.
749 AnyEvent::Impl::Glib based on Glib, slow but very stable. 837 AnyEvent::Impl::Glib based on Glib, slow but very stable.
750 AnyEvent::Impl::Tk based on Tk, very broken. 838 AnyEvent::Impl::Tk based on Tk, very broken.
751 AnyEvent::Impl::EventLib based on Event::Lib, leaks memory and worse. 839 AnyEvent::Impl::EventLib based on Event::Lib, leaks memory and worse.
752 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.
842 AnyEvent::Impl::IOAsync based on IO::Async.
843 AnyEvent::Impl::Cocoa based on Cocoa::EventLoop.
753 844
754 Backends with special needs. 845 Backends with special needs.
755 Qt requires the Qt::Application to be instantiated first, but will 846 Qt requires the Qt::Application to be instantiated first, but will
756 otherwise be picked up automatically. As long as the main program 847 otherwise be picked up automatically. As long as the main program
757 instantiates the application before any AnyEvent watchers are 848 instantiates the application before any AnyEvent watchers are
758 created, everything should just work. 849 created, everything should just work.
759 850
760 AnyEvent::Impl::Qt based on Qt. 851 AnyEvent::Impl::Qt based on Qt.
761 852
762 Support for IO::Async can only be partial, as it is too broken and
763 architecturally limited to even support the AnyEvent API. It also is
764 the only event loop that needs the loop to be set explicitly, so it
765 can only be used by a main program knowing about AnyEvent. See
766 AnyEvent::Impl::Async for the gory details.
767
768 AnyEvent::Impl::IOAsync based on IO::Async, cannot be autoprobed.
769
770 Event loops that are indirectly supported via other backends. 853 Event loops that are indirectly supported via other backends.
771 Some event loops can be supported via other modules: 854 Some event loops can be supported via other modules:
772 855
773 There is no direct support for WxWidgets (Wx) or Prima. 856 There is no direct support for WxWidgets (Wx) or Prima.
774 857
792 Contains "undef" until the first watcher is being created, before 875 Contains "undef" until the first watcher is being created, before
793 the backend has been autodetected. 876 the backend has been autodetected.
794 877
795 Afterwards it contains the event model that is being used, which is 878 Afterwards it contains the event model that is being used, which is
796 the name of the Perl class implementing the model. This class is 879 the name of the Perl class implementing the model. This class is
797 usually one of the "AnyEvent::Impl:xxx" modules, but can be any 880 usually one of the "AnyEvent::Impl::xxx" modules, but can be any
798 other class in the case AnyEvent has been extended at runtime (e.g. 881 other class in the case AnyEvent has been extended at runtime (e.g.
799 in *rxvt-unicode* it will be "urxvt::anyevent"). 882 in *rxvt-unicode* it will be "urxvt::anyevent").
800 883
801 AnyEvent::detect 884 AnyEvent::detect
802 Returns $AnyEvent::MODEL, forcing autodetection of the event model 885 Returns $AnyEvent::MODEL, forcing autodetection of the event model
803 if necessary. You should only call this function right before you 886 if necessary. You should only call this function right before you
804 would have created an AnyEvent watcher anyway, that is, as late as 887 would have created an AnyEvent watcher anyway, that is, as late as
805 possible at runtime, and not e.g. while initialising of your module. 888 possible at runtime, and not e.g. during initialisation of your
889 module.
806 890
807 If you need to do some initialisation before AnyEvent watchers are 891 If you need to do some initialisation before AnyEvent watchers are
808 created, use "post_detect". 892 created, use "post_detect".
809 893
810 $guard = AnyEvent::post_detect { BLOCK } 894 $guard = AnyEvent::post_detect { BLOCK }
811 Arranges for the code block to be executed as soon as the event 895 Arranges for the code block to be executed as soon as the event
812 model is autodetected (or immediately if this has already happened). 896 model is autodetected (or immediately if that has already happened).
813 897
814 The block will be executed *after* the actual backend has been 898 The block will be executed *after* the actual backend has been
815 detected ($AnyEvent::MODEL is set), but *before* any watchers have 899 detected ($AnyEvent::MODEL is set), but *before* any watchers have
816 been created, so it is possible to e.g. patch @AnyEvent::ISA or do 900 been created, so it is possible to e.g. patch @AnyEvent::ISA or do
817 other initialisations - see the sources of AnyEvent::Strict or 901 other initialisations - see the sources of AnyEvent::Strict or
822 creates and installs the global IO::AIO watcher in a "post_detect" 906 creates and installs the global IO::AIO watcher in a "post_detect"
823 block to avoid autodetecting the event module at load time. 907 block to avoid autodetecting the event module at load time.
824 908
825 If called in scalar or list context, then it creates and returns an 909 If called in scalar or list context, then it creates and returns an
826 object that automatically removes the callback again when it is 910 object that automatically removes the callback again when it is
911 destroyed (or "undef" when the hook was immediately executed). See
827 destroyed. See Coro::BDB for a case where this is useful. 912 AnyEvent::AIO for a case where this is useful.
913
914 Example: Create a watcher for the IO::AIO module and store it in
915 $WATCHER, but do so only do so after the event loop is initialised.
916
917 our WATCHER;
918
919 my $guard = AnyEvent::post_detect {
920 $WATCHER = AnyEvent->io (fh => IO::AIO::poll_fileno, poll => 'r', cb => \&IO::AIO::poll_cb);
921 };
922
923 # the ||= is important in case post_detect immediately runs the block,
924 # as to not clobber the newly-created watcher. assigning both watcher and
925 # post_detect guard to the same variable has the advantage of users being
926 # able to just C<undef $WATCHER> if the watcher causes them grief.
927
928 $WATCHER ||= $guard;
828 929
829 @AnyEvent::post_detect 930 @AnyEvent::post_detect
830 If there are any code references in this array (you can "push" to it 931 If there are any code references in this array (you can "push" to it
831 before or after loading AnyEvent), then they will called directly 932 before or after loading AnyEvent), then they will be called directly
832 after the event loop has been chosen. 933 after the event loop has been chosen.
833 934
834 You should check $AnyEvent::MODEL before adding to this array, 935 You should check $AnyEvent::MODEL before adding to this array,
835 though: if it is defined then the event loop has already been 936 though: if it is defined then the event loop has already been
836 detected, and the array will be ignored. 937 detected, and the array will be ignored.
837 938
838 Best use "AnyEvent::post_detect { BLOCK }" when your application 939 Best use "AnyEvent::post_detect { BLOCK }" when your application
839 allows it,as it takes care of these details. 940 allows it, as it takes care of these details.
840 941
841 This variable is mainly useful for modules that can do something 942 This variable is mainly useful for modules that can do something
842 useful when AnyEvent is used and thus want to know when it is 943 useful when AnyEvent is used and thus want to know when it is
843 initialised, but do not need to even load it by default. This array 944 initialised, but do not need to even load it by default. This array
844 provides the means to hook into AnyEvent passively, without loading 945 provides the means to hook into AnyEvent passively, without loading
845 it. 946 it.
846 947
948 Example: To load Coro::AnyEvent whenever Coro and AnyEvent are used
949 together, you could put this into Coro (this is the actual code used
950 by Coro to accomplish this):
951
952 if (defined $AnyEvent::MODEL) {
953 # AnyEvent already initialised, so load Coro::AnyEvent
954 require Coro::AnyEvent;
955 } else {
956 # AnyEvent not yet initialised, so make sure to load Coro::AnyEvent
957 # as soon as it is
958 push @AnyEvent::post_detect, sub { require Coro::AnyEvent };
959 }
960
847WHAT TO DO IN A MODULE 961WHAT TO DO IN A MODULE
848 As a module author, you should "use AnyEvent" and call AnyEvent methods 962 As a module author, you should "use AnyEvent" and call AnyEvent methods
849 freely, but you should not load a specific event module or rely on it. 963 freely, but you should not load a specific event module or rely on it.
850 964
851 Be careful when you create watchers in the module body - AnyEvent will 965 Be careful when you create watchers in the module body - AnyEvent will
858 stall the whole program, and the whole point of using events is to stay 972 stall the whole program, and the whole point of using events is to stay
859 interactive. 973 interactive.
860 974
861 It is fine, however, to call "->recv" when the user of your module 975 It is fine, however, to call "->recv" when the user of your module
862 requests it (i.e. if you create a http request object ad have a method 976 requests it (i.e. if you create a http request object ad have a method
863 called "results" that returns the results, it should call "->recv" 977 called "results" that returns the results, it may call "->recv" freely,
864 freely, as the user of your module knows what she is doing. always). 978 as the user of your module knows what she is doing. Always).
865 979
866WHAT TO DO IN THE MAIN PROGRAM 980WHAT TO DO IN THE MAIN PROGRAM
867 There will always be a single main program - the only place that should 981 There will always be a single main program - the only place that should
868 dictate which event model to use. 982 dictate which event model to use.
869 983
870 If it doesn't care, it can just "use AnyEvent" and use it itself, or not 984 If the program is not event-based, it need not do anything special, even
871 do anything special (it does not need to be event-based) and let 985 when it depends on a module that uses an AnyEvent. If the program itself
872 AnyEvent decide which implementation to chose if some module relies on 986 uses AnyEvent, but does not care which event loop is used, all it needs
873 it. 987 to do is "use AnyEvent". In either case, AnyEvent will choose the best
988 available loop implementation.
874 989
875 If the main program relies on a specific event model - for example, in 990 If the main program relies on a specific event model - for example, in
876 Gtk2 programs you have to rely on the Glib module - you should load the 991 Gtk2 programs you have to rely on the Glib module - you should load the
877 event module before loading AnyEvent or any module that uses it: 992 event module before loading AnyEvent or any module that uses it:
878 generally speaking, you should load it as early as possible. The reason 993 generally speaking, you should load it as early as possible. The reason
879 is that modules might create watchers when they are loaded, and AnyEvent 994 is that modules might create watchers when they are loaded, and AnyEvent
880 will decide on the event model to use as soon as it creates watchers, 995 will decide on the event model to use as soon as it creates watchers,
881 and it might chose the wrong one unless you load the correct one 996 and it might choose the wrong one unless you load the correct one
882 yourself. 997 yourself.
883 998
884 You can chose to use a pure-perl implementation by loading the 999 You can chose to use a pure-perl implementation by loading the
885 "AnyEvent::Impl::Perl" module, which gives you similar behaviour 1000 "AnyEvent::Impl::Perl" module, which gives you similar behaviour
886 everywhere, but letting AnyEvent chose the model is generally better. 1001 everywhere, but letting AnyEvent chose the model is generally better.
903 1018
904OTHER MODULES 1019OTHER MODULES
905 The following is a non-exhaustive list of additional modules that use 1020 The following is a non-exhaustive list of additional modules that use
906 AnyEvent as a client and can therefore be mixed easily with other 1021 AnyEvent as a client and can therefore be mixed easily with other
907 AnyEvent modules and other event loops in the same program. Some of the 1022 AnyEvent modules and other event loops in the same program. Some of the
908 modules come with AnyEvent, most are available via CPAN. 1023 modules come as part of AnyEvent, the others are available via CPAN.
909 1024
910 AnyEvent::Util 1025 AnyEvent::Util
911 Contains various utility functions that replace often-used but 1026 Contains various utility functions that replace often-used blocking
912 blocking functions such as "inet_aton" by event-/callback-based 1027 functions such as "inet_aton" with event/callback-based versions.
913 versions.
914 1028
915 AnyEvent::Socket 1029 AnyEvent::Socket
916 Provides various utility functions for (internet protocol) sockets, 1030 Provides various utility functions for (internet protocol) sockets,
917 addresses and name resolution. Also functions to create non-blocking 1031 addresses and name resolution. Also functions to create non-blocking
918 tcp connections or tcp servers, with IPv6 and SRV record support and 1032 tcp connections or tcp servers, with IPv6 and SRV record support and
919 more. 1033 more.
920 1034
921 AnyEvent::Handle 1035 AnyEvent::Handle
922 Provide read and write buffers, manages watchers for reads and 1036 Provide read and write buffers, manages watchers for reads and
923 writes, supports raw and formatted I/O, I/O queued and fully 1037 writes, supports raw and formatted I/O, I/O queued and fully
924 transparent and non-blocking SSL/TLS (via AnyEvent::TLS. 1038 transparent and non-blocking SSL/TLS (via AnyEvent::TLS).
925 1039
926 AnyEvent::DNS 1040 AnyEvent::DNS
927 Provides rich asynchronous DNS resolver capabilities. 1041 Provides rich asynchronous DNS resolver capabilities.
928 1042
1043 AnyEvent::HTTP, AnyEvent::IRC, AnyEvent::XMPP, AnyEvent::GPSD,
1044 AnyEvent::IGS, AnyEvent::FCP
1045 Implement event-based interfaces to the protocols of the same name
1046 (for the curious, IGS is the International Go Server and FCP is the
1047 Freenet Client Protocol).
1048
1049 AnyEvent::Handle::UDP
1050 Here be danger!
1051
1052 As Pauli would put it, "Not only is it not right, it's not even
1053 wrong!" - there are so many things wrong with AnyEvent::Handle::UDP,
1054 most notably its use of a stream-based API with a protocol that
1055 isn't streamable, that the only way to improve it is to delete it.
1056
1057 It features data corruption (but typically only under load) and
1058 general confusion. On top, the author is not only clueless about UDP
1059 but also fact-resistant - some gems of his understanding: "connect
1060 doesn't work with UDP", "UDP packets are not IP packets", "UDP only
1061 has datagrams, not packets", "I don't need to implement proper error
1062 checking as UDP doesn't support error checking" and so on - he
1063 doesn't even understand what's wrong with his module when it is
1064 explained to him.
1065
929 AnyEvent::HTTP 1066 AnyEvent::DBI
930 A simple-to-use HTTP library that is capable of making a lot of 1067 Executes DBI requests asynchronously in a proxy process for you,
931 concurrent HTTP requests. 1068 notifying you in an event-based way when the operation is finished.
1069
1070 AnyEvent::AIO
1071 Truly asynchronous (as opposed to non-blocking) I/O, should be in
1072 the toolbox of every event programmer. AnyEvent::AIO transparently
1073 fuses IO::AIO and AnyEvent together, giving AnyEvent access to
1074 event-based file I/O, and much more.
932 1075
933 AnyEvent::HTTPD 1076 AnyEvent::HTTPD
934 Provides a simple web application server framework. 1077 A simple embedded webserver.
935 1078
936 AnyEvent::FastPing 1079 AnyEvent::FastPing
937 The fastest ping in the west. 1080 The fastest ping in the west.
938 1081
939 AnyEvent::DBI
940 Executes DBI requests asynchronously in a proxy process.
941
942 AnyEvent::AIO
943 Truly asynchronous I/O, should be in the toolbox of every event
944 programmer. AnyEvent::AIO transparently fuses IO::AIO and AnyEvent
945 together.
946
947 AnyEvent::BDB
948 Truly asynchronous Berkeley DB access. AnyEvent::BDB transparently
949 fuses BDB and AnyEvent together.
950
951 AnyEvent::GPSD
952 A non-blocking interface to gpsd, a daemon delivering GPS
953 information.
954
955 AnyEvent::IRC
956 AnyEvent based IRC client module family (replacing the older
957 Net::IRC3).
958
959 AnyEvent::XMPP
960 AnyEvent based XMPP (Jabber protocol) module family (replacing the
961 older Net::XMPP2>.
962
963 AnyEvent::IGS
964 A non-blocking interface to the Internet Go Server protocol (used by
965 App::IGS).
966
967 Net::FCP
968 AnyEvent-based implementation of the Freenet Client Protocol,
969 birthplace of AnyEvent.
970
971 Event::ExecFlow
972 High level API for event-based execution flow control.
973
974 Coro 1082 Coro
975 Has special support for AnyEvent via Coro::AnyEvent. 1083 Has special support for AnyEvent via Coro::AnyEvent.
1084
1085SIMPLIFIED AE API
1086 Starting with version 5.0, AnyEvent officially supports a second, much
1087 simpler, API that is designed to reduce the calling, typing and memory
1088 overhead by using function call syntax and a fixed number of parameters.
1089
1090 See the AE manpage for details.
976 1091
977ERROR AND EXCEPTION HANDLING 1092ERROR AND EXCEPTION HANDLING
978 In general, AnyEvent does not do any error handling - it relies on the 1093 In general, AnyEvent does not do any error handling - it relies on the
979 caller to do that if required. The AnyEvent::Strict module (see also the 1094 caller to do that if required. The AnyEvent::Strict module (see also the
980 "PERL_ANYEVENT_STRICT" environment variable, below) provides strict 1095 "PERL_ANYEVENT_STRICT" environment variable, below) provides strict
1021 thoroughly check the arguments passed to most method calls. If it 1136 thoroughly check the arguments passed to most method calls. If it
1022 finds any problems, it will croak. 1137 finds any problems, it will croak.
1023 1138
1024 In other words, enables "strict" mode. 1139 In other words, enables "strict" mode.
1025 1140
1026 Unlike "use strict" (or it's modern cousin, "use common::sense", it 1141 Unlike "use strict" (or its modern cousin, "use common::sense", it
1027 is definitely recommended to keep it off in production. Keeping 1142 is definitely recommended to keep it off in production. Keeping
1028 "PERL_ANYEVENT_STRICT=1" in your environment while developing 1143 "PERL_ANYEVENT_STRICT=1" in your environment while developing
1029 programs can be very useful, however. 1144 programs can be very useful, however.
1030 1145
1031 "PERL_ANYEVENT_MODEL" 1146 "PERL_ANYEVENT_MODEL"
1159 warn "read: $input\n"; # output what has been read 1274 warn "read: $input\n"; # output what has been read
1160 $cv->send if $input =~ /^q/i; # quit program if /^q/i 1275 $cv->send if $input =~ /^q/i; # quit program if /^q/i
1161 }, 1276 },
1162 ); 1277 );
1163 1278
1164 my $time_watcher; # can only be used once
1165
1166 sub new_timer {
1167 $timer = AnyEvent->timer (after => 1, cb => sub { 1279 my $time_watcher = AnyEvent->timer (after => 1, interval => 1, cb => sub {
1168 warn "timeout\n"; # print 'timeout' about every second 1280 warn "timeout\n"; # print 'timeout' at most every second
1169 &new_timer; # and restart the time
1170 });
1171 } 1281 });
1172
1173 new_timer; # create first timer
1174 1282
1175 $cv->recv; # wait until user enters /^q/i 1283 $cv->recv; # wait until user enters /^q/i
1176 1284
1177REAL-WORLD EXAMPLE 1285REAL-WORLD EXAMPLE
1178 Consider the Net::FCP module. It features (among others) the following 1286 Consider the Net::FCP module. It features (among others) the following
1250 1358
1251 The actual code goes further and collects all errors ("die"s, 1359 The actual code goes further and collects all errors ("die"s,
1252 exceptions) that occurred during request processing. The "result" method 1360 exceptions) that occurred during request processing. The "result" method
1253 detects whether an exception as thrown (it is stored inside the $txn 1361 detects whether an exception as thrown (it is stored inside the $txn
1254 object) and just throws the exception, which means connection errors and 1362 object) and just throws the exception, which means connection errors and
1255 other problems get reported tot he code that tries to use the result, 1363 other problems get reported to the code that tries to use the result,
1256 not in a random callback. 1364 not in a random callback.
1257 1365
1258 All of this enables the following usage styles: 1366 All of this enables the following usage styles:
1259 1367
1260 1. Blocking: 1368 1. Blocking:
1305 through AnyEvent. The benchmark creates a lot of timers (with a zero 1413 through AnyEvent. The benchmark creates a lot of timers (with a zero
1306 timeout) and I/O watchers (watching STDOUT, a pty, to become writable, 1414 timeout) and I/O watchers (watching STDOUT, a pty, to become writable,
1307 which it is), lets them fire exactly once and destroys them again. 1415 which it is), lets them fire exactly once and destroys them again.
1308 1416
1309 Source code for this benchmark is found as eg/bench in the AnyEvent 1417 Source code for this benchmark is found as eg/bench in the AnyEvent
1310 distribution. 1418 distribution. It uses the AE interface, which makes a real difference
1419 for the EV and Perl backends only.
1311 1420
1312 Explanation of the columns 1421 Explanation of the columns
1313 *watcher* is the number of event watchers created/destroyed. Since 1422 *watcher* is the number of event watchers created/destroyed. Since
1314 different event models feature vastly different performances, each event 1423 different event models feature vastly different performances, each event
1315 loop was given a number of watchers so that overall runtime is 1424 loop was given a number of watchers so that overall runtime is
1334 *destroy* is the time, in microseconds, that it takes to destroy a 1443 *destroy* is the time, in microseconds, that it takes to destroy a
1335 single watcher. 1444 single watcher.
1336 1445
1337 Results 1446 Results
1338 name watchers bytes create invoke destroy comment 1447 name watchers bytes create invoke destroy comment
1339 EV/EV 400000 224 0.47 0.35 0.27 EV native interface 1448 EV/EV 100000 223 0.47 0.43 0.27 EV native interface
1340 EV/Any 100000 224 2.88 0.34 0.27 EV + AnyEvent watchers 1449 EV/Any 100000 223 0.48 0.42 0.26 EV + AnyEvent watchers
1341 CoroEV/Any 100000 224 2.85 0.35 0.28 coroutines + Coro::Signal 1450 Coro::EV/Any 100000 223 0.47 0.42 0.26 coroutines + Coro::Signal
1342 Perl/Any 100000 452 4.13 0.73 0.95 pure perl implementation 1451 Perl/Any 100000 431 2.70 0.74 0.92 pure perl implementation
1343 Event/Event 16000 517 32.20 31.80 0.81 Event native interface 1452 Event/Event 16000 516 31.16 31.84 0.82 Event native interface
1344 Event/Any 16000 590 35.85 31.55 1.06 Event + AnyEvent watchers 1453 Event/Any 16000 1203 42.61 34.79 1.80 Event + AnyEvent watchers
1345 IOAsync/Any 16000 989 38.10 32.77 11.13 via IO::Async::Loop::IO_Poll 1454 IOAsync/Any 16000 1911 41.92 27.45 16.81 via IO::Async::Loop::IO_Poll
1346 IOAsync/Any 16000 990 37.59 29.50 10.61 via IO::Async::Loop::Epoll 1455 IOAsync/Any 16000 1726 40.69 26.37 15.25 via IO::Async::Loop::Epoll
1347 Glib/Any 16000 1357 102.33 12.31 51.00 quadratic behaviour 1456 Glib/Any 16000 1118 89.00 12.57 51.17 quadratic behaviour
1348 Tk/Any 2000 1860 27.20 66.31 14.00 SEGV with >> 2000 watchers 1457 Tk/Any 2000 1346 20.96 10.75 8.00 SEGV with >> 2000 watchers
1349 POE/Event 2000 6328 109.99 751.67 14.02 via POE::Loop::Event 1458 POE/Any 2000 6951 108.97 795.32 14.24 via POE::Loop::Event
1350 POE/Select 2000 6027 94.54 809.13 579.80 via POE::Loop::Select 1459 POE/Any 2000 6648 94.79 774.40 575.51 via POE::Loop::Select
1351 1460
1352 Discussion 1461 Discussion
1353 The benchmark does *not* measure scalability of the event loop very 1462 The benchmark does *not* measure scalability of the event loop very
1354 well. For example, a select-based event loop (such as the pure perl one) 1463 well. For example, a select-based event loop (such as the pure perl one)
1355 can never compete with an event loop that uses epoll when the number of 1464 can never compete with an event loop that uses epoll when the number of
1366 benchmark machine, handling an event takes roughly 1600 CPU cycles with 1475 benchmark machine, handling an event takes roughly 1600 CPU cycles with
1367 EV, 3100 CPU cycles with AnyEvent's pure perl loop and almost 3000000 1476 EV, 3100 CPU cycles with AnyEvent's pure perl loop and almost 3000000
1368 CPU cycles with POE. 1477 CPU cycles with POE.
1369 1478
1370 "EV" is the sole leader regarding speed and memory use, which are both 1479 "EV" is the sole leader regarding speed and memory use, which are both
1371 maximal/minimal, respectively. Even when going through AnyEvent, it uses 1480 maximal/minimal, respectively. When using the AE API there is zero
1481 overhead (when going through the AnyEvent API create is about 5-6 times
1482 slower, with other times being equal, so still uses far less memory than
1372 far less memory than any other event loop and is still faster than Event 1483 any other event loop and is still faster than Event natively).
1373 natively.
1374 1484
1375 The pure perl implementation is hit in a few sweet spots (both the 1485 The pure perl implementation is hit in a few sweet spots (both the
1376 constant timeout and the use of a single fd hit optimisations in the 1486 constant timeout and the use of a single fd hit optimisations in the
1377 perl interpreter and the backend itself). Nevertheless this shows that 1487 perl interpreter and the backend itself). Nevertheless this shows that
1378 it adds very little overhead in itself. Like any select-based backend 1488 it adds very little overhead in itself. Like any select-based backend
1448 In this benchmark, we use 10000 socket pairs (20000 sockets), of which 1558 In this benchmark, we use 10000 socket pairs (20000 sockets), of which
1449 100 (1%) are active. This mirrors the activity of large servers with 1559 100 (1%) are active. This mirrors the activity of large servers with
1450 many connections, most of which are idle at any one point in time. 1560 many connections, most of which are idle at any one point in time.
1451 1561
1452 Source code for this benchmark is found as eg/bench2 in the AnyEvent 1562 Source code for this benchmark is found as eg/bench2 in the AnyEvent
1453 distribution. 1563 distribution. It uses the AE interface, which makes a real difference
1564 for the EV and Perl backends only.
1454 1565
1455 Explanation of the columns 1566 Explanation of the columns
1456 *sockets* is the number of sockets, and twice the number of "servers" 1567 *sockets* is the number of sockets, and twice the number of "servers"
1457 (as each server has a read and write socket end). 1568 (as each server has a read and write socket end).
1458 1569
1464 forwarding it to another server. This includes deleting the old timeout 1575 forwarding it to another server. This includes deleting the old timeout
1465 and creating a new one that moves the timeout into the future. 1576 and creating a new one that moves the timeout into the future.
1466 1577
1467 Results 1578 Results
1468 name sockets create request 1579 name sockets create request
1469 EV 20000 69.01 11.16 1580 EV 20000 62.66 7.99
1470 Perl 20000 73.32 35.87 1581 Perl 20000 68.32 32.64
1471 IOAsync 20000 157.00 98.14 epoll 1582 IOAsync 20000 174.06 101.15 epoll
1472 IOAsync 20000 159.31 616.06 poll 1583 IOAsync 20000 174.67 610.84 poll
1473 Event 20000 212.62 257.32 1584 Event 20000 202.69 242.91
1474 Glib 20000 651.16 1896.30 1585 Glib 20000 557.01 1689.52
1475 POE 20000 349.67 12317.24 uses POE::Loop::Event 1586 POE 20000 341.54 12086.32 uses POE::Loop::Event
1476 1587
1477 Discussion 1588 Discussion
1478 This benchmark *does* measure scalability and overall performance of the 1589 This benchmark *does* measure scalability and overall performance of the
1479 particular event loop. 1590 particular event loop.
1480 1591
1593 As you can see, the AnyEvent + EV combination even beats the 1704 As you can see, the AnyEvent + EV combination even beats the
1594 hand-optimised "raw sockets benchmark", while AnyEvent + its pure perl 1705 hand-optimised "raw sockets benchmark", while AnyEvent + its pure perl
1595 backend easily beats IO::Lambda and POE. 1706 backend easily beats IO::Lambda and POE.
1596 1707
1597 And even the 100% non-blocking version written using the high-level (and 1708 And even the 100% non-blocking version written using the high-level (and
1598 slow :) AnyEvent::Handle abstraction beats both POE and IO::Lambda by a 1709 slow :) AnyEvent::Handle abstraction beats both POE and IO::Lambda
1599 large margin, even though it does all of DNS, tcp-connect and socket I/O 1710 higher level ("unoptimised") abstractions by a large margin, even though
1600 in a non-blocking way. 1711 it does all of DNS, tcp-connect and socket I/O in a non-blocking way.
1601 1712
1602 The two AnyEvent benchmarks programs can be found as eg/ae0.pl and 1713 The two AnyEvent benchmarks programs can be found as eg/ae0.pl and
1603 eg/ae2.pl in the AnyEvent distribution, the remaining benchmarks are 1714 eg/ae2.pl in the AnyEvent distribution, the remaining benchmarks are
1604 part of the IO::lambda distribution and were used without any changes. 1715 part of the IO::Lambda distribution and were used without any changes.
1605 1716
1606SIGNALS 1717SIGNALS
1607 AnyEvent currently installs handlers for these signals: 1718 AnyEvent currently installs handlers for these signals:
1608 1719
1609 SIGCHLD 1720 SIGCHLD
1631 1742
1632 Feel free to install your own handler, or reset it to defaults. 1743 Feel free to install your own handler, or reset it to defaults.
1633 1744
1634RECOMMENDED/OPTIONAL MODULES 1745RECOMMENDED/OPTIONAL MODULES
1635 One of AnyEvent's main goals is to be 100% Pure-Perl(tm): only perl (and 1746 One of AnyEvent's main goals is to be 100% Pure-Perl(tm): only perl (and
1636 it's built-in modules) are required to use it. 1747 its built-in modules) are required to use it.
1637 1748
1638 That does not mean that AnyEvent won't take advantage of some additional 1749 That does not mean that AnyEvent won't take advantage of some additional
1639 modules if they are installed. 1750 modules if they are installed.
1640 1751
1641 This section epxlains which additional modules will be used, and how 1752 This section explains which additional modules will be used, and how
1642 they affect AnyEvent's operetion. 1753 they affect AnyEvent's operation.
1643 1754
1644 Async::Interrupt 1755 Async::Interrupt
1645 This slightly arcane module is used to implement fast signal 1756 This slightly arcane module is used to implement fast signal
1646 handling: To my knowledge, there is no way to do completely 1757 handling: To my knowledge, there is no way to do completely
1647 race-free and quick signal handling in pure perl. To ensure that 1758 race-free and quick signal handling in pure perl. To ensure that
1648 signals still get delivered, AnyEvent will start an interval timer 1759 signals still get delivered, AnyEvent will start an interval timer
1649 to wake up perl (and catch the signals) with soemd elay (default is 1760 to wake up perl (and catch the signals) with some delay (default is
1650 10 seconds, look for $AnyEvent::MAX_SIGNAL_LATENCY). 1761 10 seconds, look for $AnyEvent::MAX_SIGNAL_LATENCY).
1651 1762
1652 If this module is available, then it will be used to implement 1763 If this module is available, then it will be used to implement
1653 signal catching, which means that signals will not be delayed, and 1764 signal catching, which means that signals will not be delayed, and
1654 the event loop will not be interrupted regularly, which is more 1765 the event loop will not be interrupted regularly, which is more
1655 efficient (And good for battery life on laptops). 1766 efficient (and good for battery life on laptops).
1656 1767
1657 This affects not just the pure-perl event loop, but also other event 1768 This affects not just the pure-perl event loop, but also other event
1658 loops that have no signal handling on their own (e.g. Glib, Tk, Qt). 1769 loops that have no signal handling on their own (e.g. Glib, Tk, Qt).
1770
1771 Some event loops (POE, Event, Event::Lib) offer signal watchers
1772 natively, and either employ their own workarounds (POE) or use
1773 AnyEvent's workaround (using $AnyEvent::MAX_SIGNAL_LATENCY).
1774 Installing Async::Interrupt does nothing for those backends.
1659 1775
1660 EV This module isn't really "optional", as it is simply one of the 1776 EV This module isn't really "optional", as it is simply one of the
1661 backend event loops that AnyEvent can use. However, it is simply the 1777 backend event loops that AnyEvent can use. However, it is simply the
1662 best event loop available in terms of features, speed and stability: 1778 best event loop available in terms of features, speed and stability:
1663 It supports the AnyEvent API optimally, implements all the watcher 1779 It supports the AnyEvent API optimally, implements all the watcher
1665 clock is available, can take avdantage of advanced kernel interfaces 1781 clock is available, can take avdantage of advanced kernel interfaces
1666 such as "epoll" and "kqueue", and is the fastest backend *by far*. 1782 such as "epoll" and "kqueue", and is the fastest backend *by far*.
1667 You can even embed Glib/Gtk2 in it (or vice versa, see EV::Glib and 1783 You can even embed Glib/Gtk2 in it (or vice versa, see EV::Glib and
1668 Glib::EV). 1784 Glib::EV).
1669 1785
1786 If you only use backends that rely on another event loop (e.g.
1787 "Tk"), then this module will do nothing for you.
1788
1670 Guard 1789 Guard
1671 The guard module, when used, will be used to implement 1790 The guard module, when used, will be used to implement
1672 "AnyEvent::Util::guard". This speeds up guards considerably (and 1791 "AnyEvent::Util::guard". This speeds up guards considerably (and
1673 uses a lot less memory), but otherwise doesn't affect guard 1792 uses a lot less memory), but otherwise doesn't affect guard
1674 operation much. It is purely used for performance. 1793 operation much. It is purely used for performance.
1675 1794
1676 JSON and JSON::XS 1795 JSON and JSON::XS
1677 This module is required when you want to read or write JSON data via 1796 One of these modules is required when you want to read or write JSON
1678 AnyEvent::Handle. It is also written in pure-perl, but can take 1797 data via AnyEvent::Handle. JSON is also written in pure-perl, but
1679 advantage of the ulta-high-speed JSON::XS module when it is 1798 can take advantage of the ultra-high-speed JSON::XS module when it
1680 installed. 1799 is installed.
1681
1682 In fact, AnyEvent::Handle will use JSON::XS by default if it is
1683 installed.
1684 1800
1685 Net::SSLeay 1801 Net::SSLeay
1686 Implementing TLS/SSL in Perl is certainly interesting, but not very 1802 Implementing TLS/SSL in Perl is certainly interesting, but not very
1687 worthwhile: If this module is installed, then AnyEvent::Handle (with 1803 worthwhile: If this module is installed, then AnyEvent::Handle (with
1688 the help of AnyEvent::TLS), gains the ability to do TLS/SSL. 1804 the help of AnyEvent::TLS), gains the ability to do TLS/SSL.
1689 1805
1690 Time::HiRes 1806 Time::HiRes
1691 This module is part of perl since release 5.008. It will be used 1807 This module is part of perl since release 5.008. It will be used
1692 when the chosen event library does not come with a timing source on 1808 when the chosen event library does not come with a timing source of
1693 it's own. The pure-perl event loop (AnyEvent::Impl::Perl) will 1809 its own. The pure-perl event loop (AnyEvent::Impl::Perl) will
1694 additionally use it to try to use a monotonic clock for timing 1810 additionally use it to try to use a monotonic clock for timing
1695 stability. 1811 stability.
1696 1812
1697FORK 1813FORK
1698 Most event libraries are not fork-safe. The ones who are usually are 1814 Most event libraries are not fork-safe. The ones who are usually are
1699 because they rely on inefficient but fork-safe "select" or "poll" calls. 1815 because they rely on inefficient but fork-safe "select" or "poll" calls
1700 Only EV is fully fork-aware. 1816 - higher performance APIs such as BSD's kqueue or the dreaded Linux
1817 epoll are usually badly thought-out hacks that are incompatible with
1818 fork in one way or another. Only EV is fully fork-aware and ensures that
1819 you continue event-processing in both parent and child (or both, if you
1820 know what you are doing).
1821
1822 This means that, in general, you cannot fork and do event processing in
1823 the child if the event library was initialised before the fork (which
1824 usually happens when the first AnyEvent watcher is created, or the
1825 library is loaded).
1701 1826
1702 If you have to fork, you must either do so *before* creating your first 1827 If you have to fork, you must either do so *before* creating your first
1703 watcher OR you must not use AnyEvent at all in the child OR you must do 1828 watcher OR you must not use AnyEvent at all in the child OR you must do
1704 something completely out of the scope of AnyEvent. 1829 something completely out of the scope of AnyEvent.
1830
1831 The problem of doing event processing in the parent *and* the child is
1832 much more complicated: even for backends that *are* fork-aware or
1833 fork-safe, their behaviour is not usually what you want: fork clones all
1834 watchers, that means all timers, I/O watchers etc. are active in both
1835 parent and child, which is almost never what you want. USing "exec" to
1836 start worker children from some kind of manage rprocess is usually
1837 preferred, because it is much easier and cleaner, at the expense of
1838 having to have another binary.
1705 1839
1706SECURITY CONSIDERATIONS 1840SECURITY CONSIDERATIONS
1707 AnyEvent can be forced to load any event model via 1841 AnyEvent can be forced to load any event model via
1708 $ENV{PERL_ANYEVENT_MODEL}. While this cannot (to my knowledge) be used 1842 $ENV{PERL_ANYEVENT_MODEL}. While this cannot (to my knowledge) be used
1709 to execute arbitrary code or directly gain access, it can easily be used 1843 to execute arbitrary code or directly gain access, it can easily be used
1733 5.10 and check wether the leaks still show up. (Perl 5.10.0 has other 1867 5.10 and check wether the leaks still show up. (Perl 5.10.0 has other
1734 annoying memleaks, such as leaking on "map" and "grep" but it is usually 1868 annoying memleaks, such as leaking on "map" and "grep" but it is usually
1735 not as pronounced). 1869 not as pronounced).
1736 1870
1737SEE ALSO 1871SEE ALSO
1872 Tutorial/Introduction: AnyEvent::Intro.
1873
1874 FAQ: AnyEvent::FAQ.
1875
1738 Utility functions: AnyEvent::Util. 1876 Utility functions: AnyEvent::Util.
1739 1877
1740 Event modules: EV, EV::Glib, Glib::EV, Event, Glib::Event, Glib, Tk, 1878 Event modules: EV, EV::Glib, Glib::EV, Event, Glib::Event, Glib, Tk,
1741 Event::Lib, Qt, POE. 1879 Event::Lib, Qt, POE.
1742 1880
1743 Implementations: AnyEvent::Impl::EV, AnyEvent::Impl::Event, 1881 Implementations: AnyEvent::Impl::EV, AnyEvent::Impl::Event,
1744 AnyEvent::Impl::Glib, AnyEvent::Impl::Tk, AnyEvent::Impl::Perl, 1882 AnyEvent::Impl::Glib, AnyEvent::Impl::Tk, AnyEvent::Impl::Perl,
1745 AnyEvent::Impl::EventLib, AnyEvent::Impl::Qt, AnyEvent::Impl::POE, 1883 AnyEvent::Impl::EventLib, AnyEvent::Impl::Qt, AnyEvent::Impl::POE,
1746 AnyEvent::Impl::IOAsync. 1884 AnyEvent::Impl::IOAsync, Anyevent::Impl::Irssi.
1747 1885
1748 Non-blocking file handles, sockets, TCP clients and servers: 1886 Non-blocking file handles, sockets, TCP clients and servers:
1749 AnyEvent::Handle, AnyEvent::Socket, AnyEvent::TLS. 1887 AnyEvent::Handle, AnyEvent::Socket, AnyEvent::TLS.
1750 1888
1751 Asynchronous DNS: AnyEvent::DNS. 1889 Asynchronous DNS: AnyEvent::DNS.
1752 1890
1753 Coroutine support: Coro, Coro::AnyEvent, Coro::EV, Coro::Event, 1891 Thread support: Coro, Coro::AnyEvent, Coro::EV, Coro::Event.
1754 1892
1755 Nontrivial usage examples: AnyEvent::GPSD, AnyEvent::XMPP, 1893 Nontrivial usage examples: AnyEvent::GPSD, AnyEvent::IRC,
1756 AnyEvent::HTTP. 1894 AnyEvent::HTTP.
1757 1895
1758AUTHOR 1896AUTHOR
1759 Marc Lehmann <schmorp@schmorp.de> 1897 Marc Lehmann <schmorp@schmorp.de>
1760 http://home.schmorp.de/ 1898 http://home.schmorp.de/

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines