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

Comparing AnyEvent/README (file contents):
Revision 1.28 by root, Sat Jul 12 20:45:27 2008 UTC vs.
Revision 1.51 by root, Sun Aug 9 16:05:11 2009 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, POE - various supported event 4 EV, Event, Glib, Tk, Perl, Event::Lib, Irssi, rxvt-unicode, IO::Async,
5 loops 5 Qt and POE are various supported event loops/environments.
6 6
7SYNOPSIS 7SYNOPSIS
8 use AnyEvent; 8 use AnyEvent;
9 9
10 # file descriptor readable
10 my $w = AnyEvent->io (fh => $fh, poll => "r|w", cb => sub { 11 my $w = AnyEvent->io (fh => $fh, poll => "r", cb => sub { ... });
12
13 # one-shot or repeating timers
14 my $w = AnyEvent->timer (after => $seconds, cb => sub { ... });
15 my $w = AnyEvent->timer (after => $seconds, interval => $seconds, cb => ...
16
17 print AnyEvent->now; # prints current event loop time
18 print AnyEvent->time; # think Time::HiRes::time or simply CORE::time.
19
20 # POSIX signal
21 my $w = AnyEvent->signal (signal => "TERM", cb => sub { ... });
22
23 # child process exit
24 my $w = AnyEvent->child (pid => $pid, cb => sub {
25 my ($pid, $status) = @_;
11 ... 26 ...
12 }); 27 });
13 28
14 my $w = AnyEvent->timer (after => $seconds, cb => sub { 29 # called when event loop idle (if applicable)
15 ... 30 my $w = AnyEvent->idle (cb => sub { ... });
16 });
17 31
18 my $w = AnyEvent->condvar; # stores whether a condition was flagged 32 my $w = AnyEvent->condvar; # stores whether a condition was flagged
19 $w->send; # wake up current and all future recv's 33 $w->send; # wake up current and all future recv's
20 $w->recv; # enters "main loop" till $condvar gets ->send 34 $w->recv; # enters "main loop" till $condvar gets ->send
35 # use a condvar in callback mode:
36 $w->cb (sub { $_[0]->recv });
21 37
22INTRODUCTION/TUTORIAL 38INTRODUCTION/TUTORIAL
23 This manpage is mainly a reference manual. If you are interested in a 39 This manpage is mainly a reference manual. If you are interested in a
24 tutorial or some gentle introduction, have a look at the AnyEvent::Intro 40 tutorial or some gentle introduction, have a look at the AnyEvent::Intro
25 manpage. 41 manpage.
42
43SUPPORT
44 There is a mailinglist for discussing all things AnyEvent, and an IRC
45 channel, too.
46
47 See the AnyEvent project page at the Schmorpforge Ta-Sa Software
48 Repository, at <http://anyevent.schmorp.de>, for more info.
26 49
27WHY YOU SHOULD USE THIS MODULE (OR NOT) 50WHY YOU SHOULD USE THIS MODULE (OR NOT)
28 Glib, POE, IO::Async, Event... CPAN offers event models by the dozen 51 Glib, POE, IO::Async, Event... CPAN offers event models by the dozen
29 nowadays. So what is different about AnyEvent? 52 nowadays. So what is different about AnyEvent?
30 53
123 These watchers are normal Perl objects with normal Perl lifetime. After 146 These watchers are normal Perl objects with normal Perl lifetime. After
124 creating a watcher it will immediately "watch" for events and invoke the 147 creating a watcher it will immediately "watch" for events and invoke the
125 callback when the event occurs (of course, only when the event model is 148 callback when the event occurs (of course, only when the event model is
126 in control). 149 in control).
127 150
151 Note that callbacks must not permanently change global variables
152 potentially in use by the event loop (such as $_ or $[) and that
153 callbacks must not "die". The former is good programming practise in
154 Perl and the latter stems from the fact that exception handling differs
155 widely between event loops.
156
128 To disable the watcher you have to destroy it (e.g. by setting the 157 To disable the watcher you have to destroy it (e.g. by setting the
129 variable you store it in to "undef" or otherwise deleting all references 158 variable you store it in to "undef" or otherwise deleting all references
130 to it). 159 to it).
131 160
132 All watchers are created by calling a method on the "AnyEvent" class. 161 All watchers are created by calling a method on the "AnyEvent" class.
144 Note that "my $w; $w =" combination. This is necessary because in Perl, 173 Note that "my $w; $w =" combination. This is necessary because in Perl,
145 my variables are only visible after the statement in which they are 174 my variables are only visible after the statement in which they are
146 declared. 175 declared.
147 176
148 I/O WATCHERS 177 I/O WATCHERS
178 $w = AnyEvent->io (
179 fh => <filehandle_or_fileno>,
180 poll => <"r" or "w">,
181 cb => <callback>,
182 );
183
149 You can create an I/O watcher by calling the "AnyEvent->io" method with 184 You can create an I/O watcher by calling the "AnyEvent->io" method with
150 the following mandatory key-value pairs as arguments: 185 the following mandatory key-value pairs as arguments:
151 186
152 "fh" the Perl *file handle* (*not* file descriptor) to watch for events 187 "fh" is the Perl *file handle* (or a naked file descriptor) to watch for
153 (AnyEvent might or might not keep a reference to this file handle). 188 events (AnyEvent might or might not keep a reference to this file
189 handle). Note that only file handles pointing to things for which
190 non-blocking operation makes sense are allowed. This includes sockets,
191 most character devices, pipes, fifos and so on, but not for example
192 files or block devices.
193
154 "poll" must be a string that is either "r" or "w", which creates a 194 "poll" must be a string that is either "r" or "w", which creates a
155 watcher waiting for "r"eadable or "w"ritable events, respectively. "cb" 195 watcher waiting for "r"eadable or "w"ritable events, respectively.
196
156 is the callback to invoke each time the file handle becomes ready. 197 "cb" is the callback to invoke each time the file handle becomes ready.
157 198
158 Although the callback might get passed parameters, their value and 199 Although the callback might get passed parameters, their value and
159 presence is undefined and you cannot rely on them. Portable AnyEvent 200 presence is undefined and you cannot rely on them. Portable AnyEvent
160 callbacks cannot use arguments passed to I/O watcher callbacks. 201 callbacks cannot use arguments passed to I/O watcher callbacks.
161 202
175 warn "read: $input\n"; 216 warn "read: $input\n";
176 undef $w; 217 undef $w;
177 }); 218 });
178 219
179 TIME WATCHERS 220 TIME WATCHERS
221 $w = AnyEvent->timer (after => <seconds>, cb => <callback>);
222
223 $w = AnyEvent->timer (
224 after => <fractional_seconds>,
225 interval => <fractional_seconds>,
226 cb => <callback>,
227 );
228
180 You can create a time watcher by calling the "AnyEvent->timer" method 229 You can create a time watcher by calling the "AnyEvent->timer" method
181 with the following mandatory arguments: 230 with the following mandatory arguments:
182 231
183 "after" specifies after how many seconds (fractional values are 232 "after" specifies after how many seconds (fractional values are
184 supported) the callback should be invoked. "cb" is the callback to 233 supported) the callback should be invoked. "cb" is the callback to
293 In either case, if you care (and in most cases, you don't), then you 342 In either case, if you care (and in most cases, you don't), then you
294 can get whatever behaviour you want with any event loop, by taking 343 can get whatever behaviour you want with any event loop, by taking
295 the difference between "AnyEvent->time" and "AnyEvent->now" into 344 the difference between "AnyEvent->time" and "AnyEvent->now" into
296 account. 345 account.
297 346
347 AnyEvent->now_update
348 Some event loops (such as EV or AnyEvent::Impl::Perl) cache the
349 current time for each loop iteration (see the discussion of
350 AnyEvent->now, above).
351
352 When a callback runs for a long time (or when the process sleeps),
353 then this "current" time will differ substantially from the real
354 time, which might affect timers and time-outs.
355
356 When this is the case, you can call this method, which will update
357 the event loop's idea of "current time".
358
359 Note that updating the time *might* cause some events to be handled.
360
298 SIGNAL WATCHERS 361 SIGNAL WATCHERS
362 $w = AnyEvent->signal (signal => <uppercase_signal_name>, cb => <callback>);
363
299 You can watch for signals using a signal watcher, "signal" is the signal 364 You can watch for signals using a signal watcher, "signal" is the signal
300 *name* in uppercase and without any "SIG" prefix, "cb" is the Perl 365 *name* in uppercase and without any "SIG" prefix, "cb" is the Perl
301 callback to be invoked whenever a signal occurs. 366 callback to be invoked whenever a signal occurs.
302 367
303 Although the callback might get passed parameters, their value and 368 Although the callback might get passed parameters, their value and
308 invocation, and callback invocation will be synchronous. Synchronous 373 invocation, and callback invocation will be synchronous. Synchronous
309 means that it might take a while until the signal gets handled by the 374 means that it might take a while until the signal gets handled by the
310 process, but it is guaranteed not to interrupt any other callbacks. 375 process, but it is guaranteed not to interrupt any other callbacks.
311 376
312 The main advantage of using these watchers is that you can share a 377 The main advantage of using these watchers is that you can share a
313 signal between multiple watchers. 378 signal between multiple watchers, and AnyEvent will ensure that signals
379 will not interrupt your program at bad times.
314 380
315 This watcher might use %SIG, so programs overwriting those signals 381 This watcher might use %SIG (depending on the event loop used), so
316 directly will likely not work correctly. 382 programs overwriting those signals directly will likely not work
383 correctly.
317 384
318 Example: exit on SIGINT 385 Example: exit on SIGINT
319 386
320 my $w = AnyEvent->signal (signal => "INT", cb => sub { exit 1 }); 387 my $w = AnyEvent->signal (signal => "INT", cb => sub { exit 1 });
321 388
389 Signal Races, Delays and Workarounds
390 Many event loops (e.g. Glib, Tk, Qt, IO::Async) do not support attaching
391 callbacks to signals in a generic way, which is a pity, as you cannot do
392 race-free signal handling in perl, requiring C libraries for this.
393 AnyEvent will try to do it's best, which means in some cases, signals
394 will be delayed. The maximum time a signal might be delayed is specified
395 in $AnyEvent::MAX_SIGNAL_LATENCY (default: 10 seconds). This variable
396 can be changed only before the first signal watcher is created, and
397 should be left alone otherwise. This variable determines how often
398 AnyEvent polls for signals (in case a wake-up was missed). Higher values
399 will cause fewer spurious wake-ups, which is better for power and CPU
400 saving.
401
402 All these problems can be avoided by installing the optional
403 Async::Interrupt module, which works with most event loops. It will not
404 work with inherently broken event loops such as Event or Event::Lib (and
405 not with POE currently, as POE does it's own workaround with one-second
406 latency). For those, you just have to suffer the delays.
407
322 CHILD PROCESS WATCHERS 408 CHILD PROCESS WATCHERS
409 $w = AnyEvent->child (pid => <process id>, cb => <callback>);
410
323 You can also watch on a child process exit and catch its exit status. 411 You can also watch on a child process exit and catch its exit status.
324 412
325 The child process is specified by the "pid" argument (if set to 0, it 413 The child process is specified by the "pid" argument (one some backends,
326 watches for any child process exit). The watcher will trigger as often 414 using 0 watches for any child process exit, on others this will croak).
327 as status change for the child are received. This works by installing a 415 The watcher will be triggered only when the child process has finished
328 signal handler for "SIGCHLD". The callback will be called with the pid 416 and an exit status is available, not on any trace events
329 and exit status (as returned by waitpid), so unlike other watcher types, 417 (stopped/continued).
330 you *can* rely on child watcher callback arguments. 418
419 The callback will be called with the pid and exit status (as returned by
420 waitpid), so unlike other watcher types, you *can* rely on child watcher
421 callback arguments.
422
423 This watcher type works by installing a signal handler for "SIGCHLD",
424 and since it cannot be shared, nothing else should use SIGCHLD or reap
425 random child processes (waiting for specific child processes, e.g.
426 inside "system", is just fine).
331 427
332 There is a slight catch to child watchers, however: you usually start 428 There is a slight catch to child watchers, however: you usually start
333 them *after* the child process was created, and this means the process 429 them *after* the child process was created, and this means the process
334 could have exited already (and no SIGCHLD will be sent anymore). 430 could have exited already (and no SIGCHLD will be sent anymore).
335 431
336 Not all event models handle this correctly (POE doesn't), but even for 432 Not all event models handle this correctly (neither POE nor IO::Async
433 do, see their AnyEvent::Impl manpages for details), but even for event
337 event models that *do* handle this correctly, they usually need to be 434 models that *do* handle this correctly, they usually need to be loaded
338 loaded before the process exits (i.e. before you fork in the first 435 before the process exits (i.e. before you fork in the first place).
339 place). 436 AnyEvent's pure perl event loop handles all cases correctly regardless
437 of when you start the watcher.
340 438
341 This means you cannot create a child watcher as the very first thing in 439 This means you cannot create a child watcher as the very first thing in
342 an AnyEvent program, you *have* to create at least one watcher before 440 an AnyEvent program, you *have* to create at least one watcher before
343 you "fork" the child (alternatively, you can call "AnyEvent::detect"). 441 you "fork" the child (alternatively, you can call "AnyEvent::detect").
344 442
443 As most event loops do not support waiting for child events, they will
444 be emulated by AnyEvent in most cases, in which the latency and race
445 problems mentioned in the description of signal watchers apply.
446
345 Example: fork a process and wait for it 447 Example: fork a process and wait for it
346 448
347 my $done = AnyEvent->condvar; 449 my $done = AnyEvent->condvar;
348 450
349 my $pid = fork or exit 5; 451 my $pid = fork or exit 5;
350 452
351 my $w = AnyEvent->child ( 453 my $w = AnyEvent->child (
352 pid => $pid, 454 pid => $pid,
353 cb => sub { 455 cb => sub {
354 my ($pid, $status) = @_; 456 my ($pid, $status) = @_;
355 warn "pid $pid exited with status $status"; 457 warn "pid $pid exited with status $status";
356 $done->send; 458 $done->send;
357 }, 459 },
358 ); 460 );
359 461
360 # do something else, then wait for process exit 462 # do something else, then wait for process exit
361 $done->recv; 463 $done->recv;
362 464
465 IDLE WATCHERS
466 $w = AnyEvent->idle (cb => <callback>);
467
468 Sometimes there is a need to do something, but it is not so important to
469 do it instantly, but only when there is nothing better to do. This
470 "nothing better to do" is usually defined to be "no other events need
471 attention by the event loop".
472
473 Idle watchers ideally get invoked when the event loop has nothing better
474 to do, just before it would block the process to wait for new events.
475 Instead of blocking, the idle watcher is invoked.
476
477 Most event loops unfortunately do not really support idle watchers (only
478 EV, Event and Glib do it in a usable fashion) - for the rest, AnyEvent
479 will simply call the callback "from time to time".
480
481 Example: read lines from STDIN, but only process them when the program
482 is otherwise idle:
483
484 my @lines; # read data
485 my $idle_w;
486 my $io_w = AnyEvent->io (fh => \*STDIN, poll => 'r', cb => sub {
487 push @lines, scalar <STDIN>;
488
489 # start an idle watcher, if not already done
490 $idle_w ||= AnyEvent->idle (cb => sub {
491 # handle only one line, when there are lines left
492 if (my $line = shift @lines) {
493 print "handled when idle: $line";
494 } else {
495 # otherwise disable the idle watcher again
496 undef $idle_w;
497 }
498 });
499 });
500
363 CONDITION VARIABLES 501 CONDITION VARIABLES
502 $cv = AnyEvent->condvar;
503
504 $cv->send (<list>);
505 my @res = $cv->recv;
506
364 If you are familiar with some event loops you will know that all of them 507 If you are familiar with some event loops you will know that all of them
365 require you to run some blocking "loop", "run" or similar function that 508 require you to run some blocking "loop", "run" or similar function that
366 will actively watch for new events and call your callbacks. 509 will actively watch for new events and call your callbacks.
367 510
368 AnyEvent is different, it expects somebody else to run the event loop 511 AnyEvent is slightly different: it expects somebody else to run the
369 and will only block when necessary (usually when told by the user). 512 event loop and will only block when necessary (usually when told by the
513 user).
370 514
371 The instrument to do that is called a "condition variable", so called 515 The instrument to do that is called a "condition variable", so called
372 because they represent a condition that must become true. 516 because they represent a condition that must become true.
517
518 Now is probably a good time to look at the examples further below.
373 519
374 Condition variables can be created by calling the "AnyEvent->condvar" 520 Condition variables can be created by calling the "AnyEvent->condvar"
375 method, usually without arguments. The only argument pair allowed is 521 method, usually without arguments. The only argument pair allowed is
376 "cb", which specifies a callback to be called when the condition 522 "cb", which specifies a callback to be called when the condition
377 variable becomes true. 523 variable becomes true, with the condition variable as the first argument
524 (but not the results).
378 525
379 After creation, the condition variable is "false" until it becomes 526 After creation, the condition variable is "false" until it becomes
380 "true" by calling the "send" method (or calling the condition variable 527 "true" by calling the "send" method (or calling the condition variable
381 as if it were a callback, read about the caveats in the description for 528 as if it were a callback, read about the caveats in the description for
382 the "->send" method). 529 the "->send" method).
384 Condition variables are similar to callbacks, except that you can 531 Condition variables are similar to callbacks, except that you can
385 optionally wait for them. They can also be called merge points - points 532 optionally wait for them. They can also be called merge points - points
386 in time where multiple outstanding events have been processed. And yet 533 in time where multiple outstanding events have been processed. And yet
387 another way to call them is transactions - each condition variable can 534 another way to call them is transactions - each condition variable can
388 be used to represent a transaction, which finishes at some point and 535 be used to represent a transaction, which finishes at some point and
389 delivers a result. 536 delivers a result. And yet some people know them as "futures" - a
537 promise to compute/deliver something that you can wait for.
390 538
391 Condition variables are very useful to signal that something has 539 Condition variables are very useful to signal that something has
392 finished, for example, if you write a module that does asynchronous http 540 finished, for example, if you write a module that does asynchronous http
393 requests, then a condition variable would be the ideal candidate to 541 requests, then a condition variable would be the ideal candidate to
394 signal the availability of results. The user can either act when the 542 signal the availability of results. The user can either act when the
428 after => 1, 576 after => 1,
429 cb => sub { $result_ready->send }, 577 cb => sub { $result_ready->send },
430 ); 578 );
431 579
432 # this "blocks" (while handling events) till the callback 580 # this "blocks" (while handling events) till the callback
433 # calls send 581 # calls -<send
434 $result_ready->recv; 582 $result_ready->recv;
435 583
436 Example: wait for a timer, but take advantage of the fact that condition 584 Example: wait for a timer, but take advantage of the fact that condition
437 variables are also code references. 585 variables are also callable directly.
438 586
439 my $done = AnyEvent->condvar; 587 my $done = AnyEvent->condvar;
440 my $delay = AnyEvent->timer (after => 5, cb => $done); 588 my $delay = AnyEvent->timer (after => 5, cb => $done);
441 $done->recv; 589 $done->recv;
590
591 Example: Imagine an API that returns a condvar and doesn't support
592 callbacks. This is how you make a synchronous call, for example from the
593 main program:
594
595 use AnyEvent::CouchDB;
596
597 ...
598
599 my @info = $couchdb->info->recv;
600
601 And this is how you would just set a callback to be called whenever the
602 results are available:
603
604 $couchdb->info->cb (sub {
605 my @info = $_[0]->recv;
606 });
442 607
443 METHODS FOR PRODUCERS 608 METHODS FOR PRODUCERS
444 These methods should only be used by the producing side, i.e. the 609 These methods should only be used by the producing side, i.e. the
445 code/module that eventually sends the signal. Note that it is also the 610 code/module that eventually sends the signal. Note that it is also the
446 producer side which creates the condvar in most cases, but it isn't 611 producer side which creates the condvar in most cases, but it isn't
456 621
457 Any arguments passed to the "send" call will be returned by all 622 Any arguments passed to the "send" call will be returned by all
458 future "->recv" calls. 623 future "->recv" calls.
459 624
460 Condition variables are overloaded so one can call them directly (as 625 Condition variables are overloaded so one can call them directly (as
461 a code reference). Calling them directly is the same as calling 626 if they were a code reference). Calling them directly is the same as
462 "send". Note, however, that many C-based event loops do not handle 627 calling "send".
463 overloading, so as tempting as it may be, passing a condition
464 variable instead of a callback does not work. Both the pure perl and
465 EV loops support overloading, however, as well as all functions that
466 use perl to invoke a callback (as in AnyEvent::Socket and
467 AnyEvent::DNS for example).
468 628
469 $cv->croak ($error) 629 $cv->croak ($error)
470 Similar to send, but causes all call's to "->recv" to invoke 630 Similar to send, but causes all call's to "->recv" to invoke
471 "Carp::croak" with the given error message/object/scalar. 631 "Carp::croak" with the given error message/object/scalar.
472 632
473 This can be used to signal any errors to the condition variable 633 This can be used to signal any errors to the condition variable
474 user/consumer. 634 user/consumer. Doing it this way instead of calling "croak" directly
635 delays the error detetcion, but has the overwhelmign advantage that
636 it diagnoses the error at the place where the result is expected,
637 and not deep in some event clalback without connection to the actual
638 code causing the problem.
475 639
476 $cv->begin ([group callback]) 640 $cv->begin ([group callback])
477 $cv->end 641 $cv->end
478 These two methods are EXPERIMENTAL and MIGHT CHANGE.
479
480 These two methods can be used to combine many transactions/events 642 These two methods can be used to combine many transactions/events
481 into one. For example, a function that pings many hosts in parallel 643 into one. For example, a function that pings many hosts in parallel
482 might want to use a condition variable for the whole process. 644 might want to use a condition variable for the whole process.
483 645
484 Every call to "->begin" will increment a counter, and every call to 646 Every call to "->begin" will increment a counter, and every call to
485 "->end" will decrement it. If the counter reaches 0 in "->end", the 647 "->end" will decrement it. If the counter reaches 0 in "->end", the
486 (last) callback passed to "begin" will be executed. That callback is 648 (last) callback passed to "begin" will be executed. That callback is
487 *supposed* to call "->send", but that is not required. If no 649 *supposed* to call "->send", but that is not required. If no
488 callback was set, "send" will be called without any arguments. 650 callback was set, "send" will be called without any arguments.
489 651
490 Let's clarify this with the ping example: 652 You can think of "$cv->send" giving you an OR condition (one call
653 sends), while "$cv->begin" and "$cv->end" giving you an AND
654 condition (all "begin" calls must be "end"'ed before the condvar
655 sends).
656
657 Let's start with a simple example: you have two I/O watchers (for
658 example, STDOUT and STDERR for a program), and you want to wait for
659 both streams to close before activating a condvar:
660
661 my $cv = AnyEvent->condvar;
662
663 $cv->begin; # first watcher
664 my $w1 = AnyEvent->io (fh => $fh1, cb => sub {
665 defined sysread $fh1, my $buf, 4096
666 or $cv->end;
667 });
668
669 $cv->begin; # second watcher
670 my $w2 = AnyEvent->io (fh => $fh2, cb => sub {
671 defined sysread $fh2, my $buf, 4096
672 or $cv->end;
673 });
674
675 $cv->recv;
676
677 This works because for every event source (EOF on file handle),
678 there is one call to "begin", so the condvar waits for all calls to
679 "end" before sending.
680
681 The ping example mentioned above is slightly more complicated, as
682 the there are results to be passwd back, and the number of tasks
683 that are begung can potentially be zero:
491 684
492 my $cv = AnyEvent->condvar; 685 my $cv = AnyEvent->condvar;
493 686
494 my %result; 687 my %result;
495 $cv->begin (sub { $cv->send (\%result) }); 688 $cv->begin (sub { $cv->send (\%result) });
515 the loop, which serves two important purposes: first, it sets the 708 the loop, which serves two important purposes: first, it sets the
516 callback to be called once the counter reaches 0, and second, it 709 callback to be called once the counter reaches 0, and second, it
517 ensures that "send" is called even when "no" hosts are being pinged 710 ensures that "send" is called even when "no" hosts are being pinged
518 (the loop doesn't execute once). 711 (the loop doesn't execute once).
519 712
520 This is the general pattern when you "fan out" into multiple 713 This is the general pattern when you "fan out" into multiple (but
521 subrequests: use an outer "begin"/"end" pair to set the callback and 714 potentially none) subrequests: use an outer "begin"/"end" pair to
522 ensure "end" is called at least once, and then, for each subrequest 715 set the callback and ensure "end" is called at least once, and then,
523 you start, call "begin" and for each subrequest you finish, call 716 for each subrequest you start, call "begin" and for each subrequest
524 "end". 717 you finish, call "end".
525 718
526 METHODS FOR CONSUMERS 719 METHODS FOR CONSUMERS
527 These methods should only be used by the consuming side, i.e. the code 720 These methods should only be used by the consuming side, i.e. the code
528 awaits the condition. 721 awaits the condition.
529 722
538 function will call "croak". 731 function will call "croak".
539 732
540 In list context, all parameters passed to "send" will be returned, 733 In list context, all parameters passed to "send" will be returned,
541 in scalar context only the first one will be returned. 734 in scalar context only the first one will be returned.
542 735
736 Note that doing a blocking wait in a callback is not supported by
737 any event loop, that is, recursive invocation of a blocking "->recv"
738 is not allowed, and the "recv" call will "croak" if such a condition
739 is detected. This condition can be slightly loosened by using
740 Coro::AnyEvent, which allows you to do a blocking "->recv" from any
741 thread that doesn't run the event loop itself.
742
543 Not all event models support a blocking wait - some die in that case 743 Not all event models support a blocking wait - some die in that case
544 (programs might want to do that to stay interactive), so *if you are 744 (programs might want to do that to stay interactive), so *if you are
545 using this from a module, never require a blocking wait*, but let 745 using this from a module, never require a blocking wait*. Instead,
546 the caller decide whether the call will block or not (for example, 746 let the caller decide whether the call will block or not (for
547 by coupling condition variables with some kind of request results 747 example, by coupling condition variables with some kind of request
548 and supporting callbacks so the caller knows that getting the result 748 results and supporting callbacks so the caller knows that getting
549 will not block, while still supporting blocking waits if the caller 749 the result will not block, while still supporting blocking waits if
550 so desires). 750 the caller so desires).
551
552 Another reason *never* to "->recv" in a module is that you cannot
553 sensibly have two "->recv"'s in parallel, as that would require
554 multiple interpreters or coroutines/threads, none of which
555 "AnyEvent" can supply.
556
557 The Coro module, however, *can* and *does* supply coroutines and, in
558 fact, Coro::AnyEvent replaces AnyEvent's condvars by coroutine-safe
559 versions and also integrates coroutines into AnyEvent, making
560 blocking "->recv" calls perfectly safe as long as they are done from
561 another coroutine (one that doesn't run the event loop).
562 751
563 You can ensure that "-recv" never blocks by setting a callback and 752 You can ensure that "-recv" never blocks by setting a callback and
564 only calling "->recv" from within that callback (or at a later 753 only calling "->recv" from within that callback (or at a later
565 time). This will work even when the event loop does not support 754 time). This will work even when the event loop does not support
566 blocking waits otherwise. 755 blocking waits otherwise.
567 756
568 $bool = $cv->ready 757 $bool = $cv->ready
569 Returns true when the condition is "true", i.e. whether "send" or 758 Returns true when the condition is "true", i.e. whether "send" or
570 "croak" have been called. 759 "croak" have been called.
571 760
572 $cb = $cv->cb ([new callback]) 761 $cb = $cv->cb ($cb->($cv))
573 This is a mutator function that returns the callback set and 762 This is a mutator function that returns the callback set and
574 optionally replaces it before doing so. 763 optionally replaces it before doing so.
575 764
576 The callback will be called when the condition becomes "true", i.e. 765 The callback will be called when the condition becomes (or already
577 when "send" or "croak" are called, with the only argument being the 766 was) "true", i.e. when "send" or "croak" are called (or were
578 condition variable itself. Calling "recv" inside the callback or at 767 called), with the only argument being the condition variable itself.
768 Calling "recv" inside the callback or at any later time is
579 any later time is guaranteed not to block. 769 guaranteed not to block.
770
771SUPPORTED EVENT LOOPS/BACKENDS
772 The available backend classes are (every class has its own manpage):
773
774 Backends that are autoprobed when no other event loop can be found.
775 EV is the preferred backend when no other event loop seems to be in
776 use. If EV is not installed, then AnyEvent will fall back to its own
777 pure-perl implementation, which is available everywhere as it comes
778 with AnyEvent itself.
779
780 AnyEvent::Impl::EV based on EV (interface to libev, best choice).
781 AnyEvent::Impl::Perl pure-perl implementation, fast and portable.
782
783 Backends that are transparently being picked up when they are used.
784 These will be used when they are currently loaded when the first
785 watcher is created, in which case it is assumed that the application
786 is using them. This means that AnyEvent will automatically pick the
787 right backend when the main program loads an event module before
788 anything starts to create watchers. Nothing special needs to be done
789 by the main program.
790
791 AnyEvent::Impl::Event based on Event, very stable, few glitches.
792 AnyEvent::Impl::Glib based on Glib, slow but very stable.
793 AnyEvent::Impl::Tk based on Tk, very broken.
794 AnyEvent::Impl::EventLib based on Event::Lib, leaks memory and worse.
795 AnyEvent::Impl::POE based on POE, very slow, some limitations.
796 AnyEvent::Impl::Irssi used when running within irssi.
797
798 Backends with special needs.
799 Qt requires the Qt::Application to be instantiated first, but will
800 otherwise be picked up automatically. As long as the main program
801 instantiates the application before any AnyEvent watchers are
802 created, everything should just work.
803
804 AnyEvent::Impl::Qt based on Qt.
805
806 Support for IO::Async can only be partial, as it is too broken and
807 architecturally limited to even support the AnyEvent API. It also is
808 the only event loop that needs the loop to be set explicitly, so it
809 can only be used by a main program knowing about AnyEvent. See
810 AnyEvent::Impl::Async for the gory details.
811
812 AnyEvent::Impl::IOAsync based on IO::Async, cannot be autoprobed.
813
814 Event loops that are indirectly supported via other backends.
815 Some event loops can be supported via other modules:
816
817 There is no direct support for WxWidgets (Wx) or Prima.
818
819 WxWidgets has no support for watching file handles. However, you can
820 use WxWidgets through the POE adaptor, as POE has a Wx backend that
821 simply polls 20 times per second, which was considered to be too
822 horrible to even consider for AnyEvent.
823
824 Prima is not supported as nobody seems to be using it, but it has a
825 POE backend, so it can be supported through POE.
826
827 AnyEvent knows about both Prima and Wx, however, and will try to
828 load POE when detecting them, in the hope that POE will pick them
829 up, in which case everything will be automatic.
580 830
581GLOBAL VARIABLES AND FUNCTIONS 831GLOBAL VARIABLES AND FUNCTIONS
832 These are not normally required to use AnyEvent, but can be useful to
833 write AnyEvent extension modules.
834
582 $AnyEvent::MODEL 835 $AnyEvent::MODEL
583 Contains "undef" until the first watcher is being created. Then it 836 Contains "undef" until the first watcher is being created, before
837 the backend has been autodetected.
838
584 contains the event model that is being used, which is the name of 839 Afterwards it contains the event model that is being used, which is
585 the Perl class implementing the model. This class is usually one of 840 the name of the Perl class implementing the model. This class is
586 the "AnyEvent::Impl:xxx" modules, but can be any other class in the 841 usually one of the "AnyEvent::Impl:xxx" modules, but can be any
587 case AnyEvent has been extended at runtime (e.g. in *rxvt-unicode*). 842 other class in the case AnyEvent has been extended at runtime (e.g.
588 843 in *rxvt-unicode* it will be "urxvt::anyevent").
589 The known classes so far are:
590
591 AnyEvent::Impl::EV based on EV (an interface to libev, best choice).
592 AnyEvent::Impl::Event based on Event, second best choice.
593 AnyEvent::Impl::Perl pure-perl implementation, fast and portable.
594 AnyEvent::Impl::Glib based on Glib, third-best choice.
595 AnyEvent::Impl::Tk based on Tk, very bad choice.
596 AnyEvent::Impl::Qt based on Qt, cannot be autoprobed (see its docs).
597 AnyEvent::Impl::EventLib based on Event::Lib, leaks memory and worse.
598 AnyEvent::Impl::POE based on POE, not generic enough for full support.
599
600 There is no support for WxWidgets, as WxWidgets has no support for
601 watching file handles. However, you can use WxWidgets through the
602 POE Adaptor, as POE has a Wx backend that simply polls 20 times per
603 second, which was considered to be too horrible to even consider for
604 AnyEvent. Likewise, other POE backends can be used by AnyEvent by
605 using it's adaptor.
606
607 AnyEvent knows about Prima and Wx and will try to use POE when
608 autodetecting them.
609 844
610 AnyEvent::detect 845 AnyEvent::detect
611 Returns $AnyEvent::MODEL, forcing autodetection of the event model 846 Returns $AnyEvent::MODEL, forcing autodetection of the event model
612 if necessary. You should only call this function right before you 847 if necessary. You should only call this function right before you
613 would have created an AnyEvent watcher anyway, that is, as late as 848 would have created an AnyEvent watcher anyway, that is, as late as
614 possible at runtime. 849 possible at runtime, and not e.g. while initialising of your module.
850
851 If you need to do some initialisation before AnyEvent watchers are
852 created, use "post_detect".
615 853
616 $guard = AnyEvent::post_detect { BLOCK } 854 $guard = AnyEvent::post_detect { BLOCK }
617 Arranges for the code block to be executed as soon as the event 855 Arranges for the code block to be executed as soon as the event
618 model is autodetected (or immediately if this has already happened). 856 model is autodetected (or immediately if this has already happened).
619 857
858 The block will be executed *after* the actual backend has been
859 detected ($AnyEvent::MODEL is set), but *before* any watchers have
860 been created, so it is possible to e.g. patch @AnyEvent::ISA or do
861 other initialisations - see the sources of AnyEvent::Strict or
862 AnyEvent::AIO to see how this is used.
863
864 The most common usage is to create some global watchers, without
865 forcing event module detection too early, for example, AnyEvent::AIO
866 creates and installs the global IO::AIO watcher in a "post_detect"
867 block to avoid autodetecting the event module at load time.
868
620 If called in scalar or list context, then it creates and returns an 869 If called in scalar or list context, then it creates and returns an
621 object that automatically removes the callback again when it is 870 object that automatically removes the callback again when it is
871 destroyed (or "undef" when the hook was immediately executed). See
622 destroyed. See Coro::BDB for a case where this is useful. 872 AnyEvent::AIO for a case where this is useful.
873
874 Example: Create a watcher for the IO::AIO module and store it in
875 $WATCHER. Only do so after the event loop is initialised, though.
876
877 our WATCHER;
878
879 my $guard = AnyEvent::post_detect {
880 $WATCHER = AnyEvent->io (fh => IO::AIO::poll_fileno, poll => 'r', cb => \&IO::AIO::poll_cb);
881 };
882
883 # the ||= is important in case post_detect immediately runs the block,
884 # as to not clobber the newly-created watcher. assigning both watcher and
885 # post_detect guard to the same variable has the advantage of users being
886 # able to just C<undef $WATCHER> if the watcher causes them grief.
887
888 $WATCHER ||= $guard;
623 889
624 @AnyEvent::post_detect 890 @AnyEvent::post_detect
625 If there are any code references in this array (you can "push" to it 891 If there are any code references in this array (you can "push" to it
626 before or after loading AnyEvent), then they will called directly 892 before or after loading AnyEvent), then they will called directly
627 after the event loop has been chosen. 893 after the event loop has been chosen.
628 894
629 You should check $AnyEvent::MODEL before adding to this array, 895 You should check $AnyEvent::MODEL before adding to this array,
630 though: if it contains a true value then the event loop has already 896 though: if it is defined then the event loop has already been
631 been detected, and the array will be ignored. 897 detected, and the array will be ignored.
632 898
633 Best use "AnyEvent::post_detect { BLOCK }" instead. 899 Best use "AnyEvent::post_detect { BLOCK }" when your application
900 allows it,as it takes care of these details.
901
902 This variable is mainly useful for modules that can do something
903 useful when AnyEvent is used and thus want to know when it is
904 initialised, but do not need to even load it by default. This array
905 provides the means to hook into AnyEvent passively, without loading
906 it.
634 907
635WHAT TO DO IN A MODULE 908WHAT TO DO IN A MODULE
636 As a module author, you should "use AnyEvent" and call AnyEvent methods 909 As a module author, you should "use AnyEvent" and call AnyEvent methods
637 freely, but you should not load a specific event module or rely on it. 910 freely, but you should not load a specific event module or rely on it.
638 911
689 variable somewhere, waiting for it, and sending it when the program 962 variable somewhere, waiting for it, and sending it when the program
690 should exit cleanly. 963 should exit cleanly.
691 964
692OTHER MODULES 965OTHER MODULES
693 The following is a non-exhaustive list of additional modules that use 966 The following is a non-exhaustive list of additional modules that use
694 AnyEvent and can therefore be mixed easily with other AnyEvent modules 967 AnyEvent as a client and can therefore be mixed easily with other
695 in the same program. Some of the modules come with AnyEvent, some are 968 AnyEvent modules and other event loops in the same program. Some of the
696 available via CPAN. 969 modules come with AnyEvent, most are available via CPAN.
697 970
698 AnyEvent::Util 971 AnyEvent::Util
699 Contains various utility functions that replace often-used but 972 Contains various utility functions that replace often-used but
700 blocking functions such as "inet_aton" by event-/callback-based 973 blocking functions such as "inet_aton" by event-/callback-based
701 versions. 974 versions.
707 more. 980 more.
708 981
709 AnyEvent::Handle 982 AnyEvent::Handle
710 Provide read and write buffers, manages watchers for reads and 983 Provide read and write buffers, manages watchers for reads and
711 writes, supports raw and formatted I/O, I/O queued and fully 984 writes, supports raw and formatted I/O, I/O queued and fully
712 transparent and non-blocking SSL/TLS. 985 transparent and non-blocking SSL/TLS (via AnyEvent::TLS.
713 986
714 AnyEvent::DNS 987 AnyEvent::DNS
715 Provides rich asynchronous DNS resolver capabilities. 988 Provides rich asynchronous DNS resolver capabilities.
716 989
717 AnyEvent::HTTP 990 AnyEvent::HTTP
738 1011
739 AnyEvent::GPSD 1012 AnyEvent::GPSD
740 A non-blocking interface to gpsd, a daemon delivering GPS 1013 A non-blocking interface to gpsd, a daemon delivering GPS
741 information. 1014 information.
742 1015
1016 AnyEvent::IRC
1017 AnyEvent based IRC client module family (replacing the older
1018 Net::IRC3).
1019
1020 AnyEvent::XMPP
1021 AnyEvent based XMPP (Jabber protocol) module family (replacing the
1022 older Net::XMPP2>.
1023
743 AnyEvent::IGS 1024 AnyEvent::IGS
744 A non-blocking interface to the Internet Go Server protocol (used by 1025 A non-blocking interface to the Internet Go Server protocol (used by
745 App::IGS). 1026 App::IGS).
746 1027
747 Net::IRC3
748 AnyEvent based IRC client module family.
749
750 Net::XMPP2
751 AnyEvent based XMPP (Jabber protocol) module family.
752
753 Net::FCP 1028 Net::FCP
754 AnyEvent-based implementation of the Freenet Client Protocol, 1029 AnyEvent-based implementation of the Freenet Client Protocol,
755 birthplace of AnyEvent. 1030 birthplace of AnyEvent.
756 1031
757 Event::ExecFlow 1032 Event::ExecFlow
758 High level API for event-based execution flow control. 1033 High level API for event-based execution flow control.
759 1034
760 Coro 1035 Coro
761 Has special support for AnyEvent via Coro::AnyEvent. 1036 Has special support for AnyEvent via Coro::AnyEvent.
762 1037
763 IO::Lambda 1038SIMPLIFIED AE API
764 The lambda approach to I/O - don't ask, look there. Can use 1039 Starting with version 5.0, AnyEvent officially supports a second, much
765 AnyEvent. 1040 simpler, API that is designed to reduce the calling, typing and memory
1041 overhead.
766 1042
767SUPPLYING YOUR OWN EVENT MODEL INTERFACE 1043 See the AE manpage for details.
768 This is an advanced topic that you do not normally need to use AnyEvent
769 in a module. This section is only of use to event loop authors who want
770 to provide AnyEvent compatibility.
771 1044
772 If you need to support another event library which isn't directly 1045ERROR AND EXCEPTION HANDLING
773 supported by AnyEvent, you can supply your own interface to it by 1046 In general, AnyEvent does not do any error handling - it relies on the
774 pushing, before the first watcher gets created, the package name of the 1047 caller to do that if required. The AnyEvent::Strict module (see also the
775 event module and the package name of the interface to use onto 1048 "PERL_ANYEVENT_STRICT" environment variable, below) provides strict
776 @AnyEvent::REGISTRY. You can do that before and even without loading 1049 checking of all AnyEvent methods, however, which is highly useful during
777 AnyEvent, so it is reasonably cheap. 1050 development.
778 1051
779 Example: 1052 As for exception handling (i.e. runtime errors and exceptions thrown
1053 while executing a callback), this is not only highly event-loop
1054 specific, but also not in any way wrapped by this module, as this is the
1055 job of the main program.
780 1056
781 push @AnyEvent::REGISTRY, [urxvt => urxvt::anyevent::]; 1057 The pure perl event loop simply re-throws the exception (usually within
782 1058 "condvar->recv"), the Event and EV modules call "$Event/EV::DIED->()",
783 This tells AnyEvent to (literally) use the "urxvt::anyevent::" 1059 Glib uses "install_exception_handler" and so on.
784 package/class when it finds the "urxvt" package/module is already
785 loaded.
786
787 When AnyEvent is loaded and asked to find a suitable event model, it
788 will first check for the presence of urxvt by trying to "use" the
789 "urxvt::anyevent" module.
790
791 The class should provide implementations for all watcher types. See
792 AnyEvent::Impl::EV (source code), AnyEvent::Impl::Glib (Source code) and
793 so on for actual examples. Use "perldoc -m AnyEvent::Impl::Glib" to see
794 the sources.
795
796 If you don't provide "signal" and "child" watchers than AnyEvent will
797 provide suitable (hopefully) replacements.
798
799 The above example isn't fictitious, the *rxvt-unicode* (a.k.a. urxvt)
800 terminal emulator uses the above line as-is. An interface isn't included
801 in AnyEvent because it doesn't make sense outside the embedded
802 interpreter inside *rxvt-unicode*, and it is updated and maintained as
803 part of the *rxvt-unicode* distribution.
804
805 *rxvt-unicode* also cheats a bit by not providing blocking access to
806 condition variables: code blocking while waiting for a condition will
807 "die". This still works with most modules/usages, and blocking calls
808 must not be done in an interactive application, so it makes sense.
809 1060
810ENVIRONMENT VARIABLES 1061ENVIRONMENT VARIABLES
811 The following environment variables are used by this module: 1062 The following environment variables are used by this module or its
1063 submodules.
1064
1065 Note that AnyEvent will remove *all* environment variables starting with
1066 "PERL_ANYEVENT_" from %ENV when it is loaded while taint mode is
1067 enabled.
812 1068
813 "PERL_ANYEVENT_VERBOSE" 1069 "PERL_ANYEVENT_VERBOSE"
814 By default, AnyEvent will be completely silent except in fatal 1070 By default, AnyEvent will be completely silent except in fatal
815 conditions. You can set this environment variable to make AnyEvent 1071 conditions. You can set this environment variable to make AnyEvent
816 more talkative. 1072 more talkative.
819 conditions, such as not being able to load the event model specified 1075 conditions, such as not being able to load the event model specified
820 by "PERL_ANYEVENT_MODEL". 1076 by "PERL_ANYEVENT_MODEL".
821 1077
822 When set to 2 or higher, cause AnyEvent to report to STDERR which 1078 When set to 2 or higher, cause AnyEvent to report to STDERR which
823 event model it chooses. 1079 event model it chooses.
1080
1081 When set to 8 or higher, then AnyEvent will report extra information
1082 on which optional modules it loads and how it implements certain
1083 features.
824 1084
825 "PERL_ANYEVENT_STRICT" 1085 "PERL_ANYEVENT_STRICT"
826 AnyEvent does not do much argument checking by default, as thorough 1086 AnyEvent does not do much argument checking by default, as thorough
827 argument checking is very costly. Setting this variable to a true 1087 argument checking is very costly. Setting this variable to a true
828 value will cause AnyEvent to load "AnyEvent::Strict" and then to 1088 value will cause AnyEvent to load "AnyEvent::Strict" and then to
829 thoroughly check the arguments passed to most method calls. If it 1089 thoroughly check the arguments passed to most method calls. If it
830 finds any problems it will croak. 1090 finds any problems, it will croak.
831 1091
832 In other words, enables "strict" mode. 1092 In other words, enables "strict" mode.
833 1093
834 Unlike "use strict" it is definitely recommended ot keep it off in 1094 Unlike "use strict" (or it's modern cousin, "use common::sense", it
835 production. 1095 is definitely recommended to keep it off in production. Keeping
1096 "PERL_ANYEVENT_STRICT=1" in your environment while developing
1097 programs can be very useful, however.
836 1098
837 "PERL_ANYEVENT_MODEL" 1099 "PERL_ANYEVENT_MODEL"
838 This can be used to specify the event model to be used by AnyEvent, 1100 This can be used to specify the event model to be used by AnyEvent,
839 before auto detection and -probing kicks in. It must be a string 1101 before auto detection and -probing kicks in. It must be a string
840 consisting entirely of ASCII letters. The string "AnyEvent::Impl::" 1102 consisting entirely of ASCII letters. The string "AnyEvent::Impl::"
859 mentioned will be used, and preference will be given to protocols 1121 mentioned will be used, and preference will be given to protocols
860 mentioned earlier in the list. 1122 mentioned earlier in the list.
861 1123
862 This variable can effectively be used for denial-of-service attacks 1124 This variable can effectively be used for denial-of-service attacks
863 against local programs (e.g. when setuid), although the impact is 1125 against local programs (e.g. when setuid), although the impact is
864 likely small, as the program has to handle connection errors 1126 likely small, as the program has to handle conenction and other
865 already- 1127 failures anyways.
866 1128
867 Examples: "PERL_ANYEVENT_PROTOCOLS=ipv4,ipv6" - prefer IPv4 over 1129 Examples: "PERL_ANYEVENT_PROTOCOLS=ipv4,ipv6" - prefer IPv4 over
868 IPv6, but support both and try to use both. 1130 IPv6, but support both and try to use both.
869 "PERL_ANYEVENT_PROTOCOLS=ipv4" - only support IPv4, never try to 1131 "PERL_ANYEVENT_PROTOCOLS=ipv4" - only support IPv4, never try to
870 resolve or contact IPv6 addresses. 1132 resolve or contact IPv6 addresses.
881 EDNS0 in its DNS requests. 1143 EDNS0 in its DNS requests.
882 1144
883 "PERL_ANYEVENT_MAX_FORKS" 1145 "PERL_ANYEVENT_MAX_FORKS"
884 The maximum number of child processes that 1146 The maximum number of child processes that
885 "AnyEvent::Util::fork_call" will create in parallel. 1147 "AnyEvent::Util::fork_call" will create in parallel.
1148
1149 "PERL_ANYEVENT_MAX_OUTSTANDING_DNS"
1150 The default value for the "max_outstanding" parameter for the
1151 default DNS resolver - this is the maximum number of parallel DNS
1152 requests that are sent to the DNS server.
1153
1154 "PERL_ANYEVENT_RESOLV_CONF"
1155 The file to use instead of /etc/resolv.conf (or OS-specific
1156 configuration) in the default resolver. When set to the empty
1157 string, no default config will be used.
1158
1159 "PERL_ANYEVENT_CA_FILE", "PERL_ANYEVENT_CA_PATH".
1160 When neither "ca_file" nor "ca_path" was specified during
1161 AnyEvent::TLS context creation, and either of these environment
1162 variables exist, they will be used to specify CA certificate
1163 locations instead of a system-dependent default.
1164
1165 "PERL_ANYEVENT_AVOID_GUARD" and "PERL_ANYEVENT_AVOID_ASYNC_INTERRUPT"
1166 When these are set to 1, then the respective modules are not loaded.
1167 Mostly good for testing AnyEvent itself.
1168
1169SUPPLYING YOUR OWN EVENT MODEL INTERFACE
1170 This is an advanced topic that you do not normally need to use AnyEvent
1171 in a module. This section is only of use to event loop authors who want
1172 to provide AnyEvent compatibility.
1173
1174 If you need to support another event library which isn't directly
1175 supported by AnyEvent, you can supply your own interface to it by
1176 pushing, before the first watcher gets created, the package name of the
1177 event module and the package name of the interface to use onto
1178 @AnyEvent::REGISTRY. You can do that before and even without loading
1179 AnyEvent, so it is reasonably cheap.
1180
1181 Example:
1182
1183 push @AnyEvent::REGISTRY, [urxvt => urxvt::anyevent::];
1184
1185 This tells AnyEvent to (literally) use the "urxvt::anyevent::"
1186 package/class when it finds the "urxvt" package/module is already
1187 loaded.
1188
1189 When AnyEvent is loaded and asked to find a suitable event model, it
1190 will first check for the presence of urxvt by trying to "use" the
1191 "urxvt::anyevent" module.
1192
1193 The class should provide implementations for all watcher types. See
1194 AnyEvent::Impl::EV (source code), AnyEvent::Impl::Glib (Source code) and
1195 so on for actual examples. Use "perldoc -m AnyEvent::Impl::Glib" to see
1196 the sources.
1197
1198 If you don't provide "signal" and "child" watchers than AnyEvent will
1199 provide suitable (hopefully) replacements.
1200
1201 The above example isn't fictitious, the *rxvt-unicode* (a.k.a. urxvt)
1202 terminal emulator uses the above line as-is. An interface isn't included
1203 in AnyEvent because it doesn't make sense outside the embedded
1204 interpreter inside *rxvt-unicode*, and it is updated and maintained as
1205 part of the *rxvt-unicode* distribution.
1206
1207 *rxvt-unicode* also cheats a bit by not providing blocking access to
1208 condition variables: code blocking while waiting for a condition will
1209 "die". This still works with most modules/usages, and blocking calls
1210 must not be done in an interactive application, so it makes sense.
886 1211
887EXAMPLE PROGRAM 1212EXAMPLE PROGRAM
888 The following program uses an I/O watcher to read data from STDIN, a 1213 The following program uses an I/O watcher to read data from STDIN, a
889 timer to display a message once per second, and a condition variable to 1214 timer to display a message once per second, and a condition variable to
890 quit the program when the user enters quit: 1215 quit the program when the user enters quit:
1048 through AnyEvent. The benchmark creates a lot of timers (with a zero 1373 through AnyEvent. The benchmark creates a lot of timers (with a zero
1049 timeout) and I/O watchers (watching STDOUT, a pty, to become writable, 1374 timeout) and I/O watchers (watching STDOUT, a pty, to become writable,
1050 which it is), lets them fire exactly once and destroys them again. 1375 which it is), lets them fire exactly once and destroys them again.
1051 1376
1052 Source code for this benchmark is found as eg/bench in the AnyEvent 1377 Source code for this benchmark is found as eg/bench in the AnyEvent
1053 distribution. 1378 distribution. It uses the AE interface, which makes a real difference
1379 for the EV and Perl backends only.
1054 1380
1055 Explanation of the columns 1381 Explanation of the columns
1056 *watcher* is the number of event watchers created/destroyed. Since 1382 *watcher* is the number of event watchers created/destroyed. Since
1057 different event models feature vastly different performances, each event 1383 different event models feature vastly different performances, each event
1058 loop was given a number of watchers so that overall runtime is 1384 loop was given a number of watchers so that overall runtime is
1077 *destroy* is the time, in microseconds, that it takes to destroy a 1403 *destroy* is the time, in microseconds, that it takes to destroy a
1078 single watcher. 1404 single watcher.
1079 1405
1080 Results 1406 Results
1081 name watchers bytes create invoke destroy comment 1407 name watchers bytes create invoke destroy comment
1082 EV/EV 400000 244 0.56 0.46 0.31 EV native interface 1408 EV/EV 100000 223 0.47 0.43 0.27 EV native interface
1083 EV/Any 100000 244 2.50 0.46 0.29 EV + AnyEvent watchers 1409 EV/Any 100000 223 0.48 0.42 0.26 EV + AnyEvent watchers
1084 CoroEV/Any 100000 244 2.49 0.44 0.29 coroutines + Coro::Signal 1410 Coro::EV/Any 100000 223 0.47 0.42 0.26 coroutines + Coro::Signal
1085 Perl/Any 100000 513 4.92 0.87 1.12 pure perl implementation 1411 Perl/Any 100000 431 2.70 0.74 0.92 pure perl implementation
1086 Event/Event 16000 516 31.88 31.30 0.85 Event native interface 1412 Event/Event 16000 516 31.16 31.84 0.82 Event native interface
1087 Event/Any 16000 590 35.75 31.42 1.08 Event + AnyEvent watchers 1413 Event/Any 16000 1203 42.61 34.79 1.80 Event + AnyEvent watchers
1414 IOAsync/Any 16000 1911 41.92 27.45 16.81 via IO::Async::Loop::IO_Poll
1415 IOAsync/Any 16000 1726 40.69 26.37 15.25 via IO::Async::Loop::Epoll
1088 Glib/Any 16000 1357 98.22 12.41 54.00 quadratic behaviour 1416 Glib/Any 16000 1118 89.00 12.57 51.17 quadratic behaviour
1089 Tk/Any 2000 1860 26.97 67.98 14.00 SEGV with >> 2000 watchers 1417 Tk/Any 2000 1346 20.96 10.75 8.00 SEGV with >> 2000 watchers
1090 POE/Event 2000 6644 108.64 736.02 14.73 via POE::Loop::Event 1418 POE/Any 2000 6951 108.97 795.32 14.24 via POE::Loop::Event
1091 POE/Select 2000 6343 94.13 809.12 565.96 via POE::Loop::Select 1419 POE/Any 2000 6648 94.79 774.40 575.51 via POE::Loop::Select
1092 1420
1093 Discussion 1421 Discussion
1094 The benchmark does *not* measure scalability of the event loop very 1422 The benchmark does *not* measure scalability of the event loop very
1095 well. For example, a select-based event loop (such as the pure perl one) 1423 well. For example, a select-based event loop (such as the pure perl one)
1096 can never compete with an event loop that uses epoll when the number of 1424 can never compete with an event loop that uses epoll when the number of
1107 benchmark machine, handling an event takes roughly 1600 CPU cycles with 1435 benchmark machine, handling an event takes roughly 1600 CPU cycles with
1108 EV, 3100 CPU cycles with AnyEvent's pure perl loop and almost 3000000 1436 EV, 3100 CPU cycles with AnyEvent's pure perl loop and almost 3000000
1109 CPU cycles with POE. 1437 CPU cycles with POE.
1110 1438
1111 "EV" is the sole leader regarding speed and memory use, which are both 1439 "EV" is the sole leader regarding speed and memory use, which are both
1112 maximal/minimal, respectively. Even when going through AnyEvent, it uses 1440 maximal/minimal, respectively. When using the AE API there is zero
1441 overhead (when going through the AnyEvent API create is about 5-6 times
1442 slower, with other times being equal, so still uses far less memory than
1113 far less memory than any other event loop and is still faster than Event 1443 any other event loop and is still faster than Event natively).
1114 natively.
1115 1444
1116 The pure perl implementation is hit in a few sweet spots (both the 1445 The pure perl implementation is hit in a few sweet spots (both the
1117 constant timeout and the use of a single fd hit optimisations in the 1446 constant timeout and the use of a single fd hit optimisations in the
1118 perl interpreter and the backend itself). Nevertheless this shows that 1447 perl interpreter and the backend itself). Nevertheless this shows that
1119 it adds very little overhead in itself. Like any select-based backend 1448 it adds very little overhead in itself. Like any select-based backend
1121 few of them active), of course, but this was not subject of this 1450 few of them active), of course, but this was not subject of this
1122 benchmark. 1451 benchmark.
1123 1452
1124 The "Event" module has a relatively high setup and callback invocation 1453 The "Event" module has a relatively high setup and callback invocation
1125 cost, but overall scores in on the third place. 1454 cost, but overall scores in on the third place.
1455
1456 "IO::Async" performs admirably well, about on par with "Event", even
1457 when using its pure perl backend.
1126 1458
1127 "Glib"'s memory usage is quite a bit higher, but it features a faster 1459 "Glib"'s memory usage is quite a bit higher, but it features a faster
1128 callback invocation and overall ends up in the same class as "Event". 1460 callback invocation and overall ends up in the same class as "Event".
1129 However, Glib scales extremely badly, doubling the number of watchers 1461 However, Glib scales extremely badly, doubling the number of watchers
1130 increases the processing time by more than a factor of four, making it 1462 increases the processing time by more than a factor of four, making it
1186 In this benchmark, we use 10000 socket pairs (20000 sockets), of which 1518 In this benchmark, we use 10000 socket pairs (20000 sockets), of which
1187 100 (1%) are active. This mirrors the activity of large servers with 1519 100 (1%) are active. This mirrors the activity of large servers with
1188 many connections, most of which are idle at any one point in time. 1520 many connections, most of which are idle at any one point in time.
1189 1521
1190 Source code for this benchmark is found as eg/bench2 in the AnyEvent 1522 Source code for this benchmark is found as eg/bench2 in the AnyEvent
1191 distribution. 1523 distribution. It uses the AE interface, which makes a real difference
1524 for the EV and Perl backends only.
1192 1525
1193 Explanation of the columns 1526 Explanation of the columns
1194 *sockets* is the number of sockets, and twice the number of "servers" 1527 *sockets* is the number of sockets, and twice the number of "servers"
1195 (as each server has a read and write socket end). 1528 (as each server has a read and write socket end).
1196 1529
1201 single "request", that is, reading the token from the pipe and 1534 single "request", that is, reading the token from the pipe and
1202 forwarding it to another server. This includes deleting the old timeout 1535 forwarding it to another server. This includes deleting the old timeout
1203 and creating a new one that moves the timeout into the future. 1536 and creating a new one that moves the timeout into the future.
1204 1537
1205 Results 1538 Results
1206 name sockets create request 1539 name sockets create request
1207 EV 20000 69.01 11.16 1540 EV 20000 62.66 7.99
1208 Perl 20000 73.32 35.87 1541 Perl 20000 68.32 32.64
1209 Event 20000 212.62 257.32 1542 IOAsync 20000 174.06 101.15 epoll
1210 Glib 20000 651.16 1896.30 1543 IOAsync 20000 174.67 610.84 poll
1544 Event 20000 202.69 242.91
1545 Glib 20000 557.01 1689.52
1211 POE 20000 349.67 12317.24 uses POE::Loop::Event 1546 POE 20000 341.54 12086.32 uses POE::Loop::Event
1212 1547
1213 Discussion 1548 Discussion
1214 This benchmark *does* measure scalability and overall performance of the 1549 This benchmark *does* measure scalability and overall performance of the
1215 particular event loop. 1550 particular event loop.
1216 1551
1217 EV is again fastest. Since it is using epoll on my system, the setup 1552 EV is again fastest. Since it is using epoll on my system, the setup
1218 time is relatively high, though. 1553 time is relatively high, though.
1219 1554
1220 Perl surprisingly comes second. It is much faster than the C-based event 1555 Perl surprisingly comes second. It is much faster than the C-based event
1221 loops Event and Glib. 1556 loops Event and Glib.
1557
1558 IO::Async performs very well when using its epoll backend, and still
1559 quite good compared to Glib when using its pure perl backend.
1222 1560
1223 Event suffers from high setup time as well (look at its code and you 1561 Event suffers from high setup time as well (look at its code and you
1224 will understand why). Callback invocation also has a high overhead 1562 will understand why). Callback invocation also has a high overhead
1225 compared to the "$_->() for .."-style loop that the Perl event loop 1563 compared to the "$_->() for .."-style loop that the Perl event loop
1226 uses. Event uses select or poll in basically all documented 1564 uses. Event uses select or poll in basically all documented
1277 1615
1278 Summary 1616 Summary
1279 * C-based event loops perform very well with small number of watchers, 1617 * C-based event loops perform very well with small number of watchers,
1280 as the management overhead dominates. 1618 as the management overhead dominates.
1281 1619
1620 THE IO::Lambda BENCHMARK
1621 Recently I was told about the benchmark in the IO::Lambda manpage, which
1622 could be misinterpreted to make AnyEvent look bad. In fact, the
1623 benchmark simply compares IO::Lambda with POE, and IO::Lambda looks
1624 better (which shouldn't come as a surprise to anybody). As such, the
1625 benchmark is fine, and mostly shows that the AnyEvent backend from
1626 IO::Lambda isn't very optimal. But how would AnyEvent compare when used
1627 without the extra baggage? To explore this, I wrote the equivalent
1628 benchmark for AnyEvent.
1629
1630 The benchmark itself creates an echo-server, and then, for 500 times,
1631 connects to the echo server, sends a line, waits for the reply, and then
1632 creates the next connection. This is a rather bad benchmark, as it
1633 doesn't test the efficiency of the framework or much non-blocking I/O,
1634 but it is a benchmark nevertheless.
1635
1636 name runtime
1637 Lambda/select 0.330 sec
1638 + optimized 0.122 sec
1639 Lambda/AnyEvent 0.327 sec
1640 + optimized 0.138 sec
1641 Raw sockets/select 0.077 sec
1642 POE/select, components 0.662 sec
1643 POE/select, raw sockets 0.226 sec
1644 POE/select, optimized 0.404 sec
1645
1646 AnyEvent/select/nb 0.085 sec
1647 AnyEvent/EV/nb 0.068 sec
1648 +state machine 0.134 sec
1649
1650 The benchmark is also a bit unfair (my fault): the IO::Lambda/POE
1651 benchmarks actually make blocking connects and use 100% blocking I/O,
1652 defeating the purpose of an event-based solution. All of the newly
1653 written AnyEvent benchmarks use 100% non-blocking connects (using
1654 AnyEvent::Socket::tcp_connect and the asynchronous pure perl DNS
1655 resolver), so AnyEvent is at a disadvantage here, as non-blocking
1656 connects generally require a lot more bookkeeping and event handling
1657 than blocking connects (which involve a single syscall only).
1658
1659 The last AnyEvent benchmark additionally uses AnyEvent::Handle, which
1660 offers similar expressive power as POE and IO::Lambda, using
1661 conventional Perl syntax. This means that both the echo server and the
1662 client are 100% non-blocking, further placing it at a disadvantage.
1663
1664 As you can see, the AnyEvent + EV combination even beats the
1665 hand-optimised "raw sockets benchmark", while AnyEvent + its pure perl
1666 backend easily beats IO::Lambda and POE.
1667
1668 And even the 100% non-blocking version written using the high-level (and
1669 slow :) AnyEvent::Handle abstraction beats both POE and IO::Lambda by a
1670 large margin, even though it does all of DNS, tcp-connect and socket I/O
1671 in a non-blocking way.
1672
1673 The two AnyEvent benchmarks programs can be found as eg/ae0.pl and
1674 eg/ae2.pl in the AnyEvent distribution, the remaining benchmarks are
1675 part of the IO::lambda distribution and were used without any changes.
1676
1677SIGNALS
1678 AnyEvent currently installs handlers for these signals:
1679
1680 SIGCHLD
1681 A handler for "SIGCHLD" is installed by AnyEvent's child watcher
1682 emulation for event loops that do not support them natively. Also,
1683 some event loops install a similar handler.
1684
1685 Additionally, when AnyEvent is loaded and SIGCHLD is set to IGNORE,
1686 then AnyEvent will reset it to default, to avoid losing child exit
1687 statuses.
1688
1689 SIGPIPE
1690 A no-op handler is installed for "SIGPIPE" when $SIG{PIPE} is
1691 "undef" when AnyEvent gets loaded.
1692
1693 The rationale for this is that AnyEvent users usually do not really
1694 depend on SIGPIPE delivery (which is purely an optimisation for
1695 shell use, or badly-written programs), but "SIGPIPE" can cause
1696 spurious and rare program exits as a lot of people do not expect
1697 "SIGPIPE" when writing to some random socket.
1698
1699 The rationale for installing a no-op handler as opposed to ignoring
1700 it is that this way, the handler will be restored to defaults on
1701 exec.
1702
1703 Feel free to install your own handler, or reset it to defaults.
1704
1705RECOMMENDED/OPTIONAL MODULES
1706 One of AnyEvent's main goals is to be 100% Pure-Perl(tm): only perl (and
1707 it's built-in modules) are required to use it.
1708
1709 That does not mean that AnyEvent won't take advantage of some additional
1710 modules if they are installed.
1711
1712 This section epxlains which additional modules will be used, and how
1713 they affect AnyEvent's operetion.
1714
1715 Async::Interrupt
1716 This slightly arcane module is used to implement fast signal
1717 handling: To my knowledge, there is no way to do completely
1718 race-free and quick signal handling in pure perl. To ensure that
1719 signals still get delivered, AnyEvent will start an interval timer
1720 to wake up perl (and catch the signals) with some delay (default is
1721 10 seconds, look for $AnyEvent::MAX_SIGNAL_LATENCY).
1722
1723 If this module is available, then it will be used to implement
1724 signal catching, which means that signals will not be delayed, and
1725 the event loop will not be interrupted regularly, which is more
1726 efficient (And good for battery life on laptops).
1727
1728 This affects not just the pure-perl event loop, but also other event
1729 loops that have no signal handling on their own (e.g. Glib, Tk, Qt).
1730
1731 Some event loops (POE, Event, Event::Lib) offer signal watchers
1732 natively, and either employ their own workarounds (POE) or use
1733 AnyEvent's workaround (using $AnyEvent::MAX_SIGNAL_LATENCY).
1734 Installing Async::Interrupt does nothing for those backends.
1735
1736 EV This module isn't really "optional", as it is simply one of the
1737 backend event loops that AnyEvent can use. However, it is simply the
1738 best event loop available in terms of features, speed and stability:
1739 It supports the AnyEvent API optimally, implements all the watcher
1740 types in XS, does automatic timer adjustments even when no monotonic
1741 clock is available, can take avdantage of advanced kernel interfaces
1742 such as "epoll" and "kqueue", and is the fastest backend *by far*.
1743 You can even embed Glib/Gtk2 in it (or vice versa, see EV::Glib and
1744 Glib::EV).
1745
1746 Guard
1747 The guard module, when used, will be used to implement
1748 "AnyEvent::Util::guard". This speeds up guards considerably (and
1749 uses a lot less memory), but otherwise doesn't affect guard
1750 operation much. It is purely used for performance.
1751
1752 JSON and JSON::XS
1753 This module is required when you want to read or write JSON data via
1754 AnyEvent::Handle. It is also written in pure-perl, but can take
1755 advantage of the ultra-high-speed JSON::XS module when it is
1756 installed.
1757
1758 In fact, AnyEvent::Handle will use JSON::XS by default if it is
1759 installed.
1760
1761 Net::SSLeay
1762 Implementing TLS/SSL in Perl is certainly interesting, but not very
1763 worthwhile: If this module is installed, then AnyEvent::Handle (with
1764 the help of AnyEvent::TLS), gains the ability to do TLS/SSL.
1765
1766 Time::HiRes
1767 This module is part of perl since release 5.008. It will be used
1768 when the chosen event library does not come with a timing source on
1769 it's own. The pure-perl event loop (AnyEvent::Impl::Perl) will
1770 additionally use it to try to use a monotonic clock for timing
1771 stability.
1772
1282FORK 1773FORK
1283 Most event libraries are not fork-safe. The ones who are usually are 1774 Most event libraries are not fork-safe. The ones who are usually are
1284 because they rely on inefficient but fork-safe "select" or "poll" calls. 1775 because they rely on inefficient but fork-safe "select" or "poll" calls.
1285 Only EV is fully fork-aware. 1776 Only EV is fully fork-aware.
1286 1777
1287 If you have to fork, you must either do so *before* creating your first 1778 If you have to fork, you must either do so *before* creating your first
1288 watcher OR you must not use AnyEvent at all in the child. 1779 watcher OR you must not use AnyEvent at all in the child OR you must do
1780 something completely out of the scope of AnyEvent.
1289 1781
1290SECURITY CONSIDERATIONS 1782SECURITY CONSIDERATIONS
1291 AnyEvent can be forced to load any event model via 1783 AnyEvent can be forced to load any event model via
1292 $ENV{PERL_ANYEVENT_MODEL}. While this cannot (to my knowledge) be used 1784 $ENV{PERL_ANYEVENT_MODEL}. While this cannot (to my knowledge) be used
1293 to execute arbitrary code or directly gain access, it can easily be used 1785 to execute arbitrary code or directly gain access, it can easily be used
1297 1789
1298 You can make AnyEvent completely ignore this variable by deleting it 1790 You can make AnyEvent completely ignore this variable by deleting it
1299 before the first watcher gets created, e.g. with a "BEGIN" block: 1791 before the first watcher gets created, e.g. with a "BEGIN" block:
1300 1792
1301 BEGIN { delete $ENV{PERL_ANYEVENT_MODEL} } 1793 BEGIN { delete $ENV{PERL_ANYEVENT_MODEL} }
1302 1794
1303 use AnyEvent; 1795 use AnyEvent;
1304 1796
1305 Similar considerations apply to $ENV{PERL_ANYEVENT_VERBOSE}, as that can 1797 Similar considerations apply to $ENV{PERL_ANYEVENT_VERBOSE}, as that can
1306 be used to probe what backend is used and gain other information (which 1798 be used to probe what backend is used and gain other information (which
1307 is probably even less useful to an attacker than PERL_ANYEVENT_MODEL), 1799 is probably even less useful to an attacker than PERL_ANYEVENT_MODEL),
1308 and $ENV{PERL_ANYEGENT_STRICT}. 1800 and $ENV{PERL_ANYEVENT_STRICT}.
1801
1802 Note that AnyEvent will remove *all* environment variables starting with
1803 "PERL_ANYEVENT_" from %ENV when it is loaded while taint mode is
1804 enabled.
1309 1805
1310BUGS 1806BUGS
1311 Perl 5.8 has numerous memleaks that sometimes hit this module and are 1807 Perl 5.8 has numerous memleaks that sometimes hit this module and are
1312 hard to work around. If you suffer from memleaks, first upgrade to Perl 1808 hard to work around. If you suffer from memleaks, first upgrade to Perl
1313 5.10 and check wether the leaks still show up. (Perl 5.10.0 has other 1809 5.10 and check wether the leaks still show up. (Perl 5.10.0 has other
1314 annoying mamleaks, such as leaking on "map" and "grep" but it is usually 1810 annoying memleaks, such as leaking on "map" and "grep" but it is usually
1315 not as pronounced). 1811 not as pronounced).
1316 1812
1317SEE ALSO 1813SEE ALSO
1318 Utility functions: AnyEvent::Util. 1814 Utility functions: AnyEvent::Util.
1319 1815
1320 Event modules: EV, EV::Glib, Glib::EV, Event, Glib::Event, Glib, Tk, 1816 Event modules: EV, EV::Glib, Glib::EV, Event, Glib::Event, Glib, Tk,
1321 Event::Lib, Qt, POE. 1817 Event::Lib, Qt, POE.
1322 1818
1323 Implementations: AnyEvent::Impl::EV, AnyEvent::Impl::Event, 1819 Implementations: AnyEvent::Impl::EV, AnyEvent::Impl::Event,
1324 AnyEvent::Impl::Glib, AnyEvent::Impl::Tk, AnyEvent::Impl::Perl, 1820 AnyEvent::Impl::Glib, AnyEvent::Impl::Tk, AnyEvent::Impl::Perl,
1325 AnyEvent::Impl::EventLib, AnyEvent::Impl::Qt, AnyEvent::Impl::POE. 1821 AnyEvent::Impl::EventLib, AnyEvent::Impl::Qt, AnyEvent::Impl::POE,
1822 AnyEvent::Impl::IOAsync, Anyevent::Impl::Irssi.
1326 1823
1327 Non-blocking file handles, sockets, TCP clients and servers: 1824 Non-blocking file handles, sockets, TCP clients and servers:
1328 AnyEvent::Handle, AnyEvent::Socket. 1825 AnyEvent::Handle, AnyEvent::Socket, AnyEvent::TLS.
1329 1826
1330 Asynchronous DNS: AnyEvent::DNS. 1827 Asynchronous DNS: AnyEvent::DNS.
1331 1828
1332 Coroutine support: Coro, Coro::AnyEvent, Coro::EV, Coro::Event, 1829 Coroutine support: Coro, Coro::AnyEvent, Coro::EV, Coro::Event,
1333 1830
1334 Nontrivial usage examples: Net::FCP, Net::XMPP2, AnyEvent::DNS. 1831 Nontrivial usage examples: AnyEvent::GPSD, AnyEvent::XMPP,
1832 AnyEvent::HTTP.
1335 1833
1336AUTHOR 1834AUTHOR
1337 Marc Lehmann <schmorp@schmorp.de> 1835 Marc Lehmann <schmorp@schmorp.de>
1338 http://home.schmorp.de/ 1836 http://home.schmorp.de/
1339 1837

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines