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

Comparing AnyEvent/README (file contents):
Revision 1.37 by root, Mon Apr 20 14:34:18 2009 UTC vs.
Revision 1.61 by root, Wed Apr 28 14:15:55 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, 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 # if you prefer function calls, look at the L<AE> manpage for
11 # an alternative API.
12
13 # file handle or descriptor readable
10 my $w = AnyEvent->io (fh => $fh, poll => "r|w", cb => sub { ... }); 14 my $w = AnyEvent->io (fh => $fh, poll => "r", cb => sub { ... });
11 15
16 # one-shot or repeating timers
12 my $w = AnyEvent->timer (after => $seconds, cb => sub { ... }); 17 my $w = AnyEvent->timer (after => $seconds, cb => sub { ... });
13 my $w = AnyEvent->timer (after => $seconds, interval => $seconds, cb => ... 18 my $w = AnyEvent->timer (after => $seconds, interval => $seconds, cb => ...
14 19
15 print AnyEvent->now; # prints current event loop time 20 print AnyEvent->now; # prints current event loop time
16 print AnyEvent->time; # think Time::HiRes::time or simply CORE::time. 21 print AnyEvent->time; # think Time::HiRes::time or simply CORE::time.
17 22
23 # POSIX signal
18 my $w = AnyEvent->signal (signal => "TERM", cb => sub { ... }); 24 my $w = AnyEvent->signal (signal => "TERM", cb => sub { ... });
19 25
26 # child process exit
20 my $w = AnyEvent->child (pid => $pid, cb => sub { 27 my $w = AnyEvent->child (pid => $pid, cb => sub {
21 my ($pid, $status) = @_; 28 my ($pid, $status) = @_;
22 ... 29 ...
23 }); 30 });
31
32 # called when event loop idle (if applicable)
33 my $w = AnyEvent->idle (cb => sub { ... });
24 34
25 my $w = AnyEvent->condvar; # stores whether a condition was flagged 35 my $w = AnyEvent->condvar; # stores whether a condition was flagged
26 $w->send; # wake up current and all future recv's 36 $w->send; # wake up current and all future recv's
27 $w->recv; # enters "main loop" till $condvar gets ->send 37 $w->recv; # enters "main loop" till $condvar gets ->send
28 # use a condvar in callback mode: 38 # use a condvar in callback mode:
30 40
31INTRODUCTION/TUTORIAL 41INTRODUCTION/TUTORIAL
32 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
33 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
34 manpage. 44 manpage.
45
46SUPPORT
47 There is a mailinglist for discussing all things AnyEvent, and an IRC
48 channel, too.
49
50 See the AnyEvent project page at the Schmorpforge Ta-Sa Software
51 Repository, at <http://anyevent.schmorp.de>, for more info.
35 52
36WHY YOU SHOULD USE THIS MODULE (OR NOT) 53WHY YOU SHOULD USE THIS MODULE (OR NOT)
37 Glib, POE, IO::Async, Event... CPAN offers event models by the dozen 54 Glib, POE, IO::Async, Event... CPAN offers event models by the dozen
38 nowadays. So what is different about AnyEvent? 55 nowadays. So what is different about AnyEvent?
39 56
159 Note that "my $w; $w =" combination. This is necessary because in Perl, 176 Note that "my $w; $w =" combination. This is necessary because in Perl,
160 my variables are only visible after the statement in which they are 177 my variables are only visible after the statement in which they are
161 declared. 178 declared.
162 179
163 I/O WATCHERS 180 I/O WATCHERS
181 $w = AnyEvent->io (
182 fh => <filehandle_or_fileno>,
183 poll => <"r" or "w">,
184 cb => <callback>,
185 );
186
164 You can create an I/O watcher by calling the "AnyEvent->io" method with 187 You can create an I/O watcher by calling the "AnyEvent->io" method with
165 the following mandatory key-value pairs as arguments: 188 the following mandatory key-value pairs as arguments:
166 189
167 "fh" is the Perl *file handle* (*not* file descriptor) to watch for 190 "fh" is the Perl *file handle* (or a naked file descriptor) to watch for
168 events (AnyEvent might or might not keep a reference to this file 191 events (AnyEvent might or might not keep a reference to this file
169 handle). Note that only file handles pointing to things for which 192 handle). Note that only file handles pointing to things for which
170 non-blocking operation makes sense are allowed. This includes sockets, 193 non-blocking operation makes sense are allowed. This includes sockets,
171 most character devices, pipes, fifos and so on, but not for example 194 most character devices, pipes, fifos and so on, but not for example
172 files or block devices. 195 files or block devices.
196 warn "read: $input\n"; 219 warn "read: $input\n";
197 undef $w; 220 undef $w;
198 }); 221 });
199 222
200 TIME WATCHERS 223 TIME WATCHERS
224 $w = AnyEvent->timer (after => <seconds>, cb => <callback>);
225
226 $w = AnyEvent->timer (
227 after => <fractional_seconds>,
228 interval => <fractional_seconds>,
229 cb => <callback>,
230 );
231
201 You can create a time watcher by calling the "AnyEvent->timer" method 232 You can create a time watcher by calling the "AnyEvent->timer" method
202 with the following mandatory arguments: 233 with the following mandatory arguments:
203 234
204 "after" specifies after how many seconds (fractional values are 235 "after" specifies after how many seconds (fractional values are
205 supported) the callback should be invoked. "cb" is the callback to 236 supported) the callback should be invoked. "cb" is the callback to
326 time, which might affect timers and time-outs. 357 time, which might affect timers and time-outs.
327 358
328 When this is the case, you can call this method, which will update 359 When this is the case, you can call this method, which will update
329 the event loop's idea of "current time". 360 the event loop's idea of "current time".
330 361
362 A typical example would be a script in a web server (e.g.
363 "mod_perl") - when mod_perl executes the script, then the event loop
364 will have the wrong idea about the "current time" (being potentially
365 far in the past, when the script ran the last time). In that case
366 you should arrange a call to "AnyEvent->now_update" each time the
367 web server process wakes up again (e.g. at the start of your script,
368 or in a handler).
369
331 Note that updating the time *might* cause some events to be handled. 370 Note that updating the time *might* cause some events to be handled.
332 371
333 SIGNAL WATCHERS 372 SIGNAL WATCHERS
373 $w = AnyEvent->signal (signal => <uppercase_signal_name>, cb => <callback>);
374
334 You can watch for signals using a signal watcher, "signal" is the signal 375 You can watch for signals using a signal watcher, "signal" is the signal
335 *name* in uppercase and without any "SIG" prefix, "cb" is the Perl 376 *name* in uppercase and without any "SIG" prefix, "cb" is the Perl
336 callback to be invoked whenever a signal occurs. 377 callback to be invoked whenever a signal occurs.
337 378
338 Although the callback might get passed parameters, their value and 379 Although the callback might get passed parameters, their value and
343 invocation, and callback invocation will be synchronous. Synchronous 384 invocation, and callback invocation will be synchronous. Synchronous
344 means that it might take a while until the signal gets handled by the 385 means that it might take a while until the signal gets handled by the
345 process, but it is guaranteed not to interrupt any other callbacks. 386 process, but it is guaranteed not to interrupt any other callbacks.
346 387
347 The main advantage of using these watchers is that you can share a 388 The main advantage of using these watchers is that you can share a
348 signal between multiple watchers. 389 signal between multiple watchers, and AnyEvent will ensure that signals
390 will not interrupt your program at bad times.
349 391
350 This watcher might use %SIG, so programs overwriting those signals 392 This watcher might use %SIG (depending on the event loop used), so
351 directly will likely not work correctly. 393 programs overwriting those signals directly will likely not work
394 correctly.
352 395
353 Example: exit on SIGINT 396 Example: exit on SIGINT
354 397
355 my $w = AnyEvent->signal (signal => "INT", cb => sub { exit 1 }); 398 my $w = AnyEvent->signal (signal => "INT", cb => sub { exit 1 });
356 399
400 Restart Behaviour
401 While restart behaviour is up to the event loop implementation, most
402 will not restart syscalls (that includes Async::Interrupt and AnyEvent's
403 pure perl implementation).
404
405 Safe/Unsafe Signals
406 Perl signals can be either "safe" (synchronous to opcode handling) or
407 "unsafe" (asynchronous) - the former might get delayed indefinitely, the
408 latter might corrupt your memory.
409
410 AnyEvent signal handlers are, in addition, synchronous to the event
411 loop, i.e. they will not interrupt your running perl program but will
412 only be called as part of the normal event handling (just like timer,
413 I/O etc. callbacks, too).
414
415 Signal Races, Delays and Workarounds
416 Many event loops (e.g. Glib, Tk, Qt, IO::Async) do not support attaching
417 callbacks to signals in a generic way, which is a pity, as you cannot do
418 race-free signal handling in perl, requiring C libraries for this.
419 AnyEvent will try to do it's best, which means in some cases, signals
420 will be delayed. The maximum time a signal might be delayed is specified
421 in $AnyEvent::MAX_SIGNAL_LATENCY (default: 10 seconds). This variable
422 can be changed only before the first signal watcher is created, and
423 should be left alone otherwise. This variable determines how often
424 AnyEvent polls for signals (in case a wake-up was missed). Higher values
425 will cause fewer spurious wake-ups, which is better for power and CPU
426 saving.
427
428 All these problems can be avoided by installing the optional
429 Async::Interrupt module, which works with most event loops. It will not
430 work with inherently broken event loops such as Event or Event::Lib (and
431 not with POE currently, as POE does it's own workaround with one-second
432 latency). For those, you just have to suffer the delays.
433
357 CHILD PROCESS WATCHERS 434 CHILD PROCESS WATCHERS
435 $w = AnyEvent->child (pid => <process id>, cb => <callback>);
436
358 You can also watch on a child process exit and catch its exit status. 437 You can also watch on a child process exit and catch its exit status.
359 438
360 The child process is specified by the "pid" argument (if set to 0, it 439 The child process is specified by the "pid" argument (one some backends,
361 watches for any child process exit). The watcher will triggered only 440 using 0 watches for any child process exit, on others this will croak).
362 when the child process has finished and an exit status is available, not 441 The watcher will be triggered only when the child process has finished
363 on any trace events (stopped/continued). 442 and an exit status is available, not on any trace events
443 (stopped/continued).
364 444
365 The callback will be called with the pid and exit status (as returned by 445 The callback will be called with the pid and exit status (as returned by
366 waitpid), so unlike other watcher types, you *can* rely on child watcher 446 waitpid), so unlike other watcher types, you *can* rely on child watcher
367 callback arguments. 447 callback arguments.
368 448
373 453
374 There is a slight catch to child watchers, however: you usually start 454 There is a slight catch to child watchers, however: you usually start
375 them *after* the child process was created, and this means the process 455 them *after* the child process was created, and this means the process
376 could have exited already (and no SIGCHLD will be sent anymore). 456 could have exited already (and no SIGCHLD will be sent anymore).
377 457
378 Not all event models handle this correctly (POE doesn't), but even for 458 Not all event models handle this correctly (neither POE nor IO::Async
459 do, see their AnyEvent::Impl manpages for details), but even for event
379 event models that *do* handle this correctly, they usually need to be 460 models that *do* handle this correctly, they usually need to be loaded
380 loaded before the process exits (i.e. before you fork in the first 461 before the process exits (i.e. before you fork in the first place).
381 place). 462 AnyEvent's pure perl event loop handles all cases correctly regardless
463 of when you start the watcher.
382 464
383 This means you cannot create a child watcher as the very first thing in 465 This means you cannot create a child watcher as the very first thing in
384 an AnyEvent program, you *have* to create at least one watcher before 466 an AnyEvent program, you *have* to create at least one watcher before
385 you "fork" the child (alternatively, you can call "AnyEvent::detect"). 467 you "fork" the child (alternatively, you can call "AnyEvent::detect").
468
469 As most event loops do not support waiting for child events, they will
470 be emulated by AnyEvent in most cases, in which the latency and race
471 problems mentioned in the description of signal watchers apply.
386 472
387 Example: fork a process and wait for it 473 Example: fork a process and wait for it
388 474
389 my $done = AnyEvent->condvar; 475 my $done = AnyEvent->condvar;
390 476
400 ); 486 );
401 487
402 # do something else, then wait for process exit 488 # do something else, then wait for process exit
403 $done->recv; 489 $done->recv;
404 490
491 IDLE WATCHERS
492 $w = AnyEvent->idle (cb => <callback>);
493
494 Repeatedly invoke the callback after the process becomes idle, until
495 either the watcher is destroyed or new events have been detected.
496
497 Idle watchers are useful when there is a need to do something, but it is
498 not so important (or wise) to do it instantly. The callback will be
499 invoked only when there is "nothing better to do", which is usually
500 defined as "all outstanding events have been handled and no new events
501 have been detected". That means that idle watchers ideally get invoked
502 when the event loop has just polled for new events but none have been
503 detected. Instead of blocking to wait for more events, the idle watchers
504 will be invoked.
505
506 Unfortunately, most event loops do not really support idle watchers
507 (only EV, Event and Glib do it in a usable fashion) - for the rest,
508 AnyEvent will simply call the callback "from time to time".
509
510 Example: read lines from STDIN, but only process them when the program
511 is otherwise idle:
512
513 my @lines; # read data
514 my $idle_w;
515 my $io_w = AnyEvent->io (fh => \*STDIN, poll => 'r', cb => sub {
516 push @lines, scalar <STDIN>;
517
518 # start an idle watcher, if not already done
519 $idle_w ||= AnyEvent->idle (cb => sub {
520 # handle only one line, when there are lines left
521 if (my $line = shift @lines) {
522 print "handled when idle: $line";
523 } else {
524 # otherwise disable the idle watcher again
525 undef $idle_w;
526 }
527 });
528 });
529
405 CONDITION VARIABLES 530 CONDITION VARIABLES
531 $cv = AnyEvent->condvar;
532
533 $cv->send (<list>);
534 my @res = $cv->recv;
535
406 If you are familiar with some event loops you will know that all of them 536 If you are familiar with some event loops you will know that all of them
407 require you to run some blocking "loop", "run" or similar function that 537 require you to run some blocking "loop", "run" or similar function that
408 will actively watch for new events and call your callbacks. 538 will actively watch for new events and call your callbacks.
409 539
410 AnyEvent is different, it expects somebody else to run the event loop 540 AnyEvent is slightly different: it expects somebody else to run the
411 and will only block when necessary (usually when told by the user). 541 event loop and will only block when necessary (usually when told by the
542 user).
412 543
413 The instrument to do that is called a "condition variable", so called 544 The instrument to do that is called a "condition variable", so called
414 because they represent a condition that must become true. 545 because they represent a condition that must become true.
415 546
547 Now is probably a good time to look at the examples further below.
548
416 Condition variables can be created by calling the "AnyEvent->condvar" 549 Condition variables can be created by calling the "AnyEvent->condvar"
417 method, usually without arguments. The only argument pair allowed is 550 method, usually without arguments. The only argument pair allowed is
418
419 "cb", which specifies a callback to be called when the condition 551 "cb", which specifies a callback to be called when the condition
420 variable becomes true, with the condition variable as the first argument 552 variable becomes true, with the condition variable as the first argument
421 (but not the results). 553 (but not the results).
422 554
423 After creation, the condition variable is "false" until it becomes 555 After creation, the condition variable is "false" until it becomes
428 Condition variables are similar to callbacks, except that you can 560 Condition variables are similar to callbacks, except that you can
429 optionally wait for them. They can also be called merge points - points 561 optionally wait for them. They can also be called merge points - points
430 in time where multiple outstanding events have been processed. And yet 562 in time where multiple outstanding events have been processed. And yet
431 another way to call them is transactions - each condition variable can 563 another way to call them is transactions - each condition variable can
432 be used to represent a transaction, which finishes at some point and 564 be used to represent a transaction, which finishes at some point and
433 delivers a result. 565 delivers a result. And yet some people know them as "futures" - a
566 promise to compute/deliver something that you can wait for.
434 567
435 Condition variables are very useful to signal that something has 568 Condition variables are very useful to signal that something has
436 finished, for example, if you write a module that does asynchronous http 569 finished, for example, if you write a module that does asynchronous http
437 requests, then a condition variable would be the ideal candidate to 570 requests, then a condition variable would be the ideal candidate to
438 signal the availability of results. The user can either act when the 571 signal the availability of results. The user can either act when the
459 which eventually calls "-> send", and the "consumer side", which waits 592 which eventually calls "-> send", and the "consumer side", which waits
460 for the send to occur. 593 for the send to occur.
461 594
462 Example: wait for a timer. 595 Example: wait for a timer.
463 596
464 # wait till the result is ready 597 # condition: "wait till the timer is fired"
465 my $result_ready = AnyEvent->condvar; 598 my $timer_fired = AnyEvent->condvar;
466 599
467 # do something such as adding a timer 600 # create the timer - we could wait for, say
468 # or socket watcher the calls $result_ready->send 601 # a handle becomign ready, or even an
469 # when the "result" is ready. 602 # AnyEvent::HTTP request to finish, but
470 # in this case, we simply use a timer: 603 # in this case, we simply use a timer:
471 my $w = AnyEvent->timer ( 604 my $w = AnyEvent->timer (
472 after => 1, 605 after => 1,
473 cb => sub { $result_ready->send }, 606 cb => sub { $timer_fired->send },
474 ); 607 );
475 608
476 # this "blocks" (while handling events) till the callback 609 # this "blocks" (while handling events) till the callback
477 # calls send 610 # calls ->send
478 $result_ready->recv; 611 $timer_fired->recv;
479 612
480 Example: wait for a timer, but take advantage of the fact that condition 613 Example: wait for a timer, but take advantage of the fact that condition
481 variables are also code references. 614 variables are also callable directly.
482 615
483 my $done = AnyEvent->condvar; 616 my $done = AnyEvent->condvar;
484 my $delay = AnyEvent->timer (after => 5, cb => $done); 617 my $delay = AnyEvent->timer (after => 5, cb => $done);
485 $done->recv; 618 $done->recv;
486 619
492 625
493 ... 626 ...
494 627
495 my @info = $couchdb->info->recv; 628 my @info = $couchdb->info->recv;
496 629
497 And this is how you would just ste a callback to be called whenever the 630 And this is how you would just set a callback to be called whenever the
498 results are available: 631 results are available:
499 632
500 $couchdb->info->cb (sub { 633 $couchdb->info->cb (sub {
501 my @info = $_[0]->recv; 634 my @info = $_[0]->recv;
502 }); 635 });
517 650
518 Any arguments passed to the "send" call will be returned by all 651 Any arguments passed to the "send" call will be returned by all
519 future "->recv" calls. 652 future "->recv" calls.
520 653
521 Condition variables are overloaded so one can call them directly (as 654 Condition variables are overloaded so one can call them directly (as
522 a code reference). Calling them directly is the same as calling 655 if they were a code reference). Calling them directly is the same as
523 "send". Note, however, that many C-based event loops do not handle 656 calling "send".
524 overloading, so as tempting as it may be, passing a condition
525 variable instead of a callback does not work. Both the pure perl and
526 EV loops support overloading, however, as well as all functions that
527 use perl to invoke a callback (as in AnyEvent::Socket and
528 AnyEvent::DNS for example).
529 657
530 $cv->croak ($error) 658 $cv->croak ($error)
531 Similar to send, but causes all call's to "->recv" to invoke 659 Similar to send, but causes all call's to "->recv" to invoke
532 "Carp::croak" with the given error message/object/scalar. 660 "Carp::croak" with the given error message/object/scalar.
533 661
534 This can be used to signal any errors to the condition variable 662 This can be used to signal any errors to the condition variable
535 user/consumer. 663 user/consumer. Doing it this way instead of calling "croak" directly
664 delays the error detetcion, but has the overwhelmign advantage that
665 it diagnoses the error at the place where the result is expected,
666 and not deep in some event clalback without connection to the actual
667 code causing the problem.
536 668
537 $cv->begin ([group callback]) 669 $cv->begin ([group callback])
538 $cv->end 670 $cv->end
539 These two methods are EXPERIMENTAL and MIGHT CHANGE.
540
541 These two methods can be used to combine many transactions/events 671 These two methods can be used to combine many transactions/events
542 into one. For example, a function that pings many hosts in parallel 672 into one. For example, a function that pings many hosts in parallel
543 might want to use a condition variable for the whole process. 673 might want to use a condition variable for the whole process.
544 674
545 Every call to "->begin" will increment a counter, and every call to 675 Every call to "->begin" will increment a counter, and every call to
546 "->end" will decrement it. If the counter reaches 0 in "->end", the 676 "->end" will decrement it. If the counter reaches 0 in "->end", the
547 (last) callback passed to "begin" will be executed. That callback is 677 (last) callback passed to "begin" will be executed, passing the
548 *supposed* to call "->send", but that is not required. If no 678 condvar as first argument. That callback is *supposed* to call
679 "->send", but that is not required. If no group callback was set,
549 callback was set, "send" will be called without any arguments. 680 "send" will be called without any arguments.
550 681
551 Let's clarify this with the ping example: 682 You can think of "$cv->send" giving you an OR condition (one call
683 sends), while "$cv->begin" and "$cv->end" giving you an AND
684 condition (all "begin" calls must be "end"'ed before the condvar
685 sends).
686
687 Let's start with a simple example: you have two I/O watchers (for
688 example, STDOUT and STDERR for a program), and you want to wait for
689 both streams to close before activating a condvar:
552 690
553 my $cv = AnyEvent->condvar; 691 my $cv = AnyEvent->condvar;
554 692
693 $cv->begin; # first watcher
694 my $w1 = AnyEvent->io (fh => $fh1, cb => sub {
695 defined sysread $fh1, my $buf, 4096
696 or $cv->end;
697 });
698
699 $cv->begin; # second watcher
700 my $w2 = AnyEvent->io (fh => $fh2, cb => sub {
701 defined sysread $fh2, my $buf, 4096
702 or $cv->end;
703 });
704
705 $cv->recv;
706
707 This works because for every event source (EOF on file handle),
708 there is one call to "begin", so the condvar waits for all calls to
709 "end" before sending.
710
711 The ping example mentioned above is slightly more complicated, as
712 the there are results to be passwd back, and the number of tasks
713 that are begung can potentially be zero:
714
715 my $cv = AnyEvent->condvar;
716
555 my %result; 717 my %result;
556 $cv->begin (sub { $cv->send (\%result) }); 718 $cv->begin (sub { shift->send (\%result) });
557 719
558 for my $host (@list_of_hosts) { 720 for my $host (@list_of_hosts) {
559 $cv->begin; 721 $cv->begin;
560 ping_host_then_call_callback $host, sub { 722 ping_host_then_call_callback $host, sub {
561 $result{$host} = ...; 723 $result{$host} = ...;
576 the loop, which serves two important purposes: first, it sets the 738 the loop, which serves two important purposes: first, it sets the
577 callback to be called once the counter reaches 0, and second, it 739 callback to be called once the counter reaches 0, and second, it
578 ensures that "send" is called even when "no" hosts are being pinged 740 ensures that "send" is called even when "no" hosts are being pinged
579 (the loop doesn't execute once). 741 (the loop doesn't execute once).
580 742
581 This is the general pattern when you "fan out" into multiple 743 This is the general pattern when you "fan out" into multiple (but
582 subrequests: use an outer "begin"/"end" pair to set the callback and 744 potentially none) subrequests: use an outer "begin"/"end" pair to
583 ensure "end" is called at least once, and then, for each subrequest 745 set the callback and ensure "end" is called at least once, and then,
584 you start, call "begin" and for each subrequest you finish, call 746 for each subrequest you start, call "begin" and for each subrequest
585 "end". 747 you finish, call "end".
586 748
587 METHODS FOR CONSUMERS 749 METHODS FOR CONSUMERS
588 These methods should only be used by the consuming side, i.e. the code 750 These methods should only be used by the consuming side, i.e. the code
589 awaits the condition. 751 awaits the condition.
590 752
599 function will call "croak". 761 function will call "croak".
600 762
601 In list context, all parameters passed to "send" will be returned, 763 In list context, all parameters passed to "send" will be returned,
602 in scalar context only the first one will be returned. 764 in scalar context only the first one will be returned.
603 765
766 Note that doing a blocking wait in a callback is not supported by
767 any event loop, that is, recursive invocation of a blocking "->recv"
768 is not allowed, and the "recv" call will "croak" if such a condition
769 is detected. This condition can be slightly loosened by using
770 Coro::AnyEvent, which allows you to do a blocking "->recv" from any
771 thread that doesn't run the event loop itself.
772
604 Not all event models support a blocking wait - some die in that case 773 Not all event models support a blocking wait - some die in that case
605 (programs might want to do that to stay interactive), so *if you are 774 (programs might want to do that to stay interactive), so *if you are
606 using this from a module, never require a blocking wait*, but let 775 using this from a module, never require a blocking wait*. Instead,
607 the caller decide whether the call will block or not (for example, 776 let the caller decide whether the call will block or not (for
608 by coupling condition variables with some kind of request results 777 example, by coupling condition variables with some kind of request
609 and supporting callbacks so the caller knows that getting the result 778 results and supporting callbacks so the caller knows that getting
610 will not block, while still supporting blocking waits if the caller 779 the result will not block, while still supporting blocking waits if
611 so desires). 780 the caller so desires).
612
613 Another reason *never* to "->recv" in a module is that you cannot
614 sensibly have two "->recv"'s in parallel, as that would require
615 multiple interpreters or coroutines/threads, none of which
616 "AnyEvent" can supply.
617
618 The Coro module, however, *can* and *does* supply coroutines and, in
619 fact, Coro::AnyEvent replaces AnyEvent's condvars by coroutine-safe
620 versions and also integrates coroutines into AnyEvent, making
621 blocking "->recv" calls perfectly safe as long as they are done from
622 another coroutine (one that doesn't run the event loop).
623 781
624 You can ensure that "-recv" never blocks by setting a callback and 782 You can ensure that "-recv" never blocks by setting a callback and
625 only calling "->recv" from within that callback (or at a later 783 only calling "->recv" from within that callback (or at a later
626 time). This will work even when the event loop does not support 784 time). This will work even when the event loop does not support
627 blocking waits otherwise. 785 blocking waits otherwise.
632 790
633 $cb = $cv->cb ($cb->($cv)) 791 $cb = $cv->cb ($cb->($cv))
634 This is a mutator function that returns the callback set and 792 This is a mutator function that returns the callback set and
635 optionally replaces it before doing so. 793 optionally replaces it before doing so.
636 794
637 The callback will be called when the condition becomes "true", i.e. 795 The callback will be called when the condition becomes (or already
638 when "send" or "croak" are called, with the only argument being the 796 was) "true", i.e. when "send" or "croak" are called (or were
639 condition variable itself. Calling "recv" inside the callback or at 797 called), with the only argument being the condition variable itself.
798 Calling "recv" inside the callback or at any later time is
640 any later time is guaranteed not to block. 799 guaranteed not to block.
800
801SUPPORTED EVENT LOOPS/BACKENDS
802 The available backend classes are (every class has its own manpage):
803
804 Backends that are autoprobed when no other event loop can be found.
805 EV is the preferred backend when no other event loop seems to be in
806 use. If EV is not installed, then AnyEvent will fall back to its own
807 pure-perl implementation, which is available everywhere as it comes
808 with AnyEvent itself.
809
810 AnyEvent::Impl::EV based on EV (interface to libev, best choice).
811 AnyEvent::Impl::Perl pure-perl implementation, fast and portable.
812
813 Backends that are transparently being picked up when they are used.
814 These will be used when they are currently loaded when the first
815 watcher is created, in which case it is assumed that the application
816 is using them. This means that AnyEvent will automatically pick the
817 right backend when the main program loads an event module before
818 anything starts to create watchers. Nothing special needs to be done
819 by the main program.
820
821 AnyEvent::Impl::Event based on Event, very stable, few glitches.
822 AnyEvent::Impl::Glib based on Glib, slow but very stable.
823 AnyEvent::Impl::Tk based on Tk, very broken.
824 AnyEvent::Impl::EventLib based on Event::Lib, leaks memory and worse.
825 AnyEvent::Impl::POE based on POE, very slow, some limitations.
826 AnyEvent::Impl::Irssi used when running within irssi.
827
828 Backends with special needs.
829 Qt requires the Qt::Application to be instantiated first, but will
830 otherwise be picked up automatically. As long as the main program
831 instantiates the application before any AnyEvent watchers are
832 created, everything should just work.
833
834 AnyEvent::Impl::Qt based on Qt.
835
836 Support for IO::Async can only be partial, as it is too broken and
837 architecturally limited to even support the AnyEvent API. It also is
838 the only event loop that needs the loop to be set explicitly, so it
839 can only be used by a main program knowing about AnyEvent. See
840 AnyEvent::Impl::Async for the gory details.
841
842 AnyEvent::Impl::IOAsync based on IO::Async, cannot be autoprobed.
843
844 Event loops that are indirectly supported via other backends.
845 Some event loops can be supported via other modules:
846
847 There is no direct support for WxWidgets (Wx) or Prima.
848
849 WxWidgets has no support for watching file handles. However, you can
850 use WxWidgets through the POE adaptor, as POE has a Wx backend that
851 simply polls 20 times per second, which was considered to be too
852 horrible to even consider for AnyEvent.
853
854 Prima is not supported as nobody seems to be using it, but it has a
855 POE backend, so it can be supported through POE.
856
857 AnyEvent knows about both Prima and Wx, however, and will try to
858 load POE when detecting them, in the hope that POE will pick them
859 up, in which case everything will be automatic.
641 860
642GLOBAL VARIABLES AND FUNCTIONS 861GLOBAL VARIABLES AND FUNCTIONS
862 These are not normally required to use AnyEvent, but can be useful to
863 write AnyEvent extension modules.
864
643 $AnyEvent::MODEL 865 $AnyEvent::MODEL
644 Contains "undef" until the first watcher is being created. Then it 866 Contains "undef" until the first watcher is being created, before
867 the backend has been autodetected.
868
645 contains the event model that is being used, which is the name of 869 Afterwards it contains the event model that is being used, which is
646 the Perl class implementing the model. This class is usually one of 870 the name of the Perl class implementing the model. This class is
647 the "AnyEvent::Impl:xxx" modules, but can be any other class in the 871 usually one of the "AnyEvent::Impl:xxx" modules, but can be any
648 case AnyEvent has been extended at runtime (e.g. in *rxvt-unicode*). 872 other class in the case AnyEvent has been extended at runtime (e.g.
649 873 in *rxvt-unicode* it will be "urxvt::anyevent").
650 The known classes so far are:
651
652 AnyEvent::Impl::EV based on EV (an interface to libev, best choice).
653 AnyEvent::Impl::Event based on Event, second best choice.
654 AnyEvent::Impl::Perl pure-perl implementation, fast and portable.
655 AnyEvent::Impl::Glib based on Glib, third-best choice.
656 AnyEvent::Impl::Tk based on Tk, very bad choice.
657 AnyEvent::Impl::Qt based on Qt, cannot be autoprobed (see its docs).
658 AnyEvent::Impl::EventLib based on Event::Lib, leaks memory and worse.
659 AnyEvent::Impl::POE based on POE, not generic enough for full support.
660
661 There is no support for WxWidgets, as WxWidgets has no support for
662 watching file handles. However, you can use WxWidgets through the
663 POE Adaptor, as POE has a Wx backend that simply polls 20 times per
664 second, which was considered to be too horrible to even consider for
665 AnyEvent. Likewise, other POE backends can be used by AnyEvent by
666 using it's adaptor.
667
668 AnyEvent knows about Prima and Wx and will try to use POE when
669 autodetecting them.
670 874
671 AnyEvent::detect 875 AnyEvent::detect
672 Returns $AnyEvent::MODEL, forcing autodetection of the event model 876 Returns $AnyEvent::MODEL, forcing autodetection of the event model
673 if necessary. You should only call this function right before you 877 if necessary. You should only call this function right before you
674 would have created an AnyEvent watcher anyway, that is, as late as 878 would have created an AnyEvent watcher anyway, that is, as late as
675 possible at runtime. 879 possible at runtime, and not e.g. while initialising of your module.
880
881 If you need to do some initialisation before AnyEvent watchers are
882 created, use "post_detect".
676 883
677 $guard = AnyEvent::post_detect { BLOCK } 884 $guard = AnyEvent::post_detect { BLOCK }
678 Arranges for the code block to be executed as soon as the event 885 Arranges for the code block to be executed as soon as the event
679 model is autodetected (or immediately if this has already happened). 886 model is autodetected (or immediately if this has already happened).
680 887
888 The block will be executed *after* the actual backend has been
889 detected ($AnyEvent::MODEL is set), but *before* any watchers have
890 been created, so it is possible to e.g. patch @AnyEvent::ISA or do
891 other initialisations - see the sources of AnyEvent::Strict or
892 AnyEvent::AIO to see how this is used.
893
894 The most common usage is to create some global watchers, without
895 forcing event module detection too early, for example, AnyEvent::AIO
896 creates and installs the global IO::AIO watcher in a "post_detect"
897 block to avoid autodetecting the event module at load time.
898
681 If called in scalar or list context, then it creates and returns an 899 If called in scalar or list context, then it creates and returns an
682 object that automatically removes the callback again when it is 900 object that automatically removes the callback again when it is
901 destroyed (or "undef" when the hook was immediately executed). See
683 destroyed. See Coro::BDB for a case where this is useful. 902 AnyEvent::AIO for a case where this is useful.
903
904 Example: Create a watcher for the IO::AIO module and store it in
905 $WATCHER. Only do so after the event loop is initialised, though.
906
907 our WATCHER;
908
909 my $guard = AnyEvent::post_detect {
910 $WATCHER = AnyEvent->io (fh => IO::AIO::poll_fileno, poll => 'r', cb => \&IO::AIO::poll_cb);
911 };
912
913 # the ||= is important in case post_detect immediately runs the block,
914 # as to not clobber the newly-created watcher. assigning both watcher and
915 # post_detect guard to the same variable has the advantage of users being
916 # able to just C<undef $WATCHER> if the watcher causes them grief.
917
918 $WATCHER ||= $guard;
684 919
685 @AnyEvent::post_detect 920 @AnyEvent::post_detect
686 If there are any code references in this array (you can "push" to it 921 If there are any code references in this array (you can "push" to it
687 before or after loading AnyEvent), then they will called directly 922 before or after loading AnyEvent), then they will called directly
688 after the event loop has been chosen. 923 after the event loop has been chosen.
689 924
690 You should check $AnyEvent::MODEL before adding to this array, 925 You should check $AnyEvent::MODEL before adding to this array,
691 though: if it contains a true value then the event loop has already 926 though: if it is defined then the event loop has already been
692 been detected, and the array will be ignored. 927 detected, and the array will be ignored.
693 928
694 Best use "AnyEvent::post_detect { BLOCK }" instead. 929 Best use "AnyEvent::post_detect { BLOCK }" when your application
930 allows it, as it takes care of these details.
931
932 This variable is mainly useful for modules that can do something
933 useful when AnyEvent is used and thus want to know when it is
934 initialised, but do not need to even load it by default. This array
935 provides the means to hook into AnyEvent passively, without loading
936 it.
937
938 Example: To load Coro::AnyEvent whenever Coro and AnyEvent are used
939 together, you could put this into Coro (this is the actual code used
940 by Coro to accomplish this):
941
942 if (defined $AnyEvent::MODEL) {
943 # AnyEvent already initialised, so load Coro::AnyEvent
944 require Coro::AnyEvent;
945 } else {
946 # AnyEvent not yet initialised, so make sure to load Coro::AnyEvent
947 # as soon as it is
948 push @AnyEvent::post_detect, sub { require Coro::AnyEvent };
949 }
695 950
696WHAT TO DO IN A MODULE 951WHAT TO DO IN A MODULE
697 As a module author, you should "use AnyEvent" and call AnyEvent methods 952 As a module author, you should "use AnyEvent" and call AnyEvent methods
698 freely, but you should not load a specific event module or rely on it. 953 freely, but you should not load a specific event module or rely on it.
699 954
750 variable somewhere, waiting for it, and sending it when the program 1005 variable somewhere, waiting for it, and sending it when the program
751 should exit cleanly. 1006 should exit cleanly.
752 1007
753OTHER MODULES 1008OTHER MODULES
754 The following is a non-exhaustive list of additional modules that use 1009 The following is a non-exhaustive list of additional modules that use
755 AnyEvent and can therefore be mixed easily with other AnyEvent modules 1010 AnyEvent as a client and can therefore be mixed easily with other
756 in the same program. Some of the modules come with AnyEvent, some are 1011 AnyEvent modules and other event loops in the same program. Some of the
757 available via CPAN. 1012 modules come with AnyEvent, most are available via CPAN.
758 1013
759 AnyEvent::Util 1014 AnyEvent::Util
760 Contains various utility functions that replace often-used but 1015 Contains various utility functions that replace often-used but
761 blocking functions such as "inet_aton" by event-/callback-based 1016 blocking functions such as "inet_aton" by event-/callback-based
762 versions. 1017 versions.
768 more. 1023 more.
769 1024
770 AnyEvent::Handle 1025 AnyEvent::Handle
771 Provide read and write buffers, manages watchers for reads and 1026 Provide read and write buffers, manages watchers for reads and
772 writes, supports raw and formatted I/O, I/O queued and fully 1027 writes, supports raw and formatted I/O, I/O queued and fully
773 transparent and non-blocking SSL/TLS. 1028 transparent and non-blocking SSL/TLS (via AnyEvent::TLS.
774 1029
775 AnyEvent::DNS 1030 AnyEvent::DNS
776 Provides rich asynchronous DNS resolver capabilities. 1031 Provides rich asynchronous DNS resolver capabilities.
777 1032
778 AnyEvent::HTTP 1033 AnyEvent::HTTP
799 1054
800 AnyEvent::GPSD 1055 AnyEvent::GPSD
801 A non-blocking interface to gpsd, a daemon delivering GPS 1056 A non-blocking interface to gpsd, a daemon delivering GPS
802 information. 1057 information.
803 1058
1059 AnyEvent::IRC
1060 AnyEvent based IRC client module family (replacing the older
1061 Net::IRC3).
1062
1063 AnyEvent::XMPP
1064 AnyEvent based XMPP (Jabber protocol) module family (replacing the
1065 older Net::XMPP2>.
1066
804 AnyEvent::IGS 1067 AnyEvent::IGS
805 A non-blocking interface to the Internet Go Server protocol (used by 1068 A non-blocking interface to the Internet Go Server protocol (used by
806 App::IGS). 1069 App::IGS).
807 1070
808 AnyEvent::IRC
809 AnyEvent based IRC client module family (replacing the older
810 Net::IRC3).
811
812 Net::XMPP2
813 AnyEvent based XMPP (Jabber protocol) module family.
814
815 Net::FCP 1071 Net::FCP
816 AnyEvent-based implementation of the Freenet Client Protocol, 1072 AnyEvent-based implementation of the Freenet Client Protocol,
817 birthplace of AnyEvent. 1073 birthplace of AnyEvent.
818 1074
819 Event::ExecFlow 1075 Event::ExecFlow
820 High level API for event-based execution flow control. 1076 High level API for event-based execution flow control.
821 1077
822 Coro 1078 Coro
823 Has special support for AnyEvent via Coro::AnyEvent. 1079 Has special support for AnyEvent via Coro::AnyEvent.
824 1080
825 IO::Lambda 1081SIMPLIFIED AE API
826 The lambda approach to I/O - don't ask, look there. Can use 1082 Starting with version 5.0, AnyEvent officially supports a second, much
827 AnyEvent. 1083 simpler, API that is designed to reduce the calling, typing and memory
1084 overhead by using function call syntax and a fixed number of parameters.
1085
1086 See the AE manpage for details.
828 1087
829ERROR AND EXCEPTION HANDLING 1088ERROR AND EXCEPTION HANDLING
830 In general, AnyEvent does not do any error handling - it relies on the 1089 In general, AnyEvent does not do any error handling - it relies on the
831 caller to do that if required. The AnyEvent::Strict module (see also the 1090 caller to do that if required. The AnyEvent::Strict module (see also the
832 "PERL_ANYEVENT_STRICT" environment variable, below) provides strict 1091 "PERL_ANYEVENT_STRICT" environment variable, below) provides strict
842 "condvar->recv"), the Event and EV modules call "$Event/EV::DIED->()", 1101 "condvar->recv"), the Event and EV modules call "$Event/EV::DIED->()",
843 Glib uses "install_exception_handler" and so on. 1102 Glib uses "install_exception_handler" and so on.
844 1103
845ENVIRONMENT VARIABLES 1104ENVIRONMENT VARIABLES
846 The following environment variables are used by this module or its 1105 The following environment variables are used by this module or its
847 submodules: 1106 submodules.
1107
1108 Note that AnyEvent will remove *all* environment variables starting with
1109 "PERL_ANYEVENT_" from %ENV when it is loaded while taint mode is
1110 enabled.
848 1111
849 "PERL_ANYEVENT_VERBOSE" 1112 "PERL_ANYEVENT_VERBOSE"
850 By default, AnyEvent will be completely silent except in fatal 1113 By default, AnyEvent will be completely silent except in fatal
851 conditions. You can set this environment variable to make AnyEvent 1114 conditions. You can set this environment variable to make AnyEvent
852 more talkative. 1115 more talkative.
855 conditions, such as not being able to load the event model specified 1118 conditions, such as not being able to load the event model specified
856 by "PERL_ANYEVENT_MODEL". 1119 by "PERL_ANYEVENT_MODEL".
857 1120
858 When set to 2 or higher, cause AnyEvent to report to STDERR which 1121 When set to 2 or higher, cause AnyEvent to report to STDERR which
859 event model it chooses. 1122 event model it chooses.
1123
1124 When set to 8 or higher, then AnyEvent will report extra information
1125 on which optional modules it loads and how it implements certain
1126 features.
860 1127
861 "PERL_ANYEVENT_STRICT" 1128 "PERL_ANYEVENT_STRICT"
862 AnyEvent does not do much argument checking by default, as thorough 1129 AnyEvent does not do much argument checking by default, as thorough
863 argument checking is very costly. Setting this variable to a true 1130 argument checking is very costly. Setting this variable to a true
864 value will cause AnyEvent to load "AnyEvent::Strict" and then to 1131 value will cause AnyEvent to load "AnyEvent::Strict" and then to
865 thoroughly check the arguments passed to most method calls. If it 1132 thoroughly check the arguments passed to most method calls. If it
866 finds any problems it will croak. 1133 finds any problems, it will croak.
867 1134
868 In other words, enables "strict" mode. 1135 In other words, enables "strict" mode.
869 1136
870 Unlike "use strict", it is definitely recommended ot keep it off in 1137 Unlike "use strict" (or it's modern cousin, "use common::sense", it
871 production. Keeping "PERL_ANYEVENT_STRICT=1" in your environment 1138 is definitely recommended to keep it off in production. Keeping
1139 "PERL_ANYEVENT_STRICT=1" in your environment while developing
872 while developing programs can be very useful, however. 1140 programs can be very useful, however.
873 1141
874 "PERL_ANYEVENT_MODEL" 1142 "PERL_ANYEVENT_MODEL"
875 This can be used to specify the event model to be used by AnyEvent, 1143 This can be used to specify the event model to be used by AnyEvent,
876 before auto detection and -probing kicks in. It must be a string 1144 before auto detection and -probing kicks in. It must be a string
877 consisting entirely of ASCII letters. The string "AnyEvent::Impl::" 1145 consisting entirely of ASCII letters. The string "AnyEvent::Impl::"
918 EDNS0 in its DNS requests. 1186 EDNS0 in its DNS requests.
919 1187
920 "PERL_ANYEVENT_MAX_FORKS" 1188 "PERL_ANYEVENT_MAX_FORKS"
921 The maximum number of child processes that 1189 The maximum number of child processes that
922 "AnyEvent::Util::fork_call" will create in parallel. 1190 "AnyEvent::Util::fork_call" will create in parallel.
1191
1192 "PERL_ANYEVENT_MAX_OUTSTANDING_DNS"
1193 The default value for the "max_outstanding" parameter for the
1194 default DNS resolver - this is the maximum number of parallel DNS
1195 requests that are sent to the DNS server.
1196
1197 "PERL_ANYEVENT_RESOLV_CONF"
1198 The file to use instead of /etc/resolv.conf (or OS-specific
1199 configuration) in the default resolver. When set to the empty
1200 string, no default config will be used.
1201
1202 "PERL_ANYEVENT_CA_FILE", "PERL_ANYEVENT_CA_PATH".
1203 When neither "ca_file" nor "ca_path" was specified during
1204 AnyEvent::TLS context creation, and either of these environment
1205 variables exist, they will be used to specify CA certificate
1206 locations instead of a system-dependent default.
1207
1208 "PERL_ANYEVENT_AVOID_GUARD" and "PERL_ANYEVENT_AVOID_ASYNC_INTERRUPT"
1209 When these are set to 1, then the respective modules are not loaded.
1210 Mostly good for testing AnyEvent itself.
923 1211
924SUPPLYING YOUR OWN EVENT MODEL INTERFACE 1212SUPPLYING YOUR OWN EVENT MODEL INTERFACE
925 This is an advanced topic that you do not normally need to use AnyEvent 1213 This is an advanced topic that you do not normally need to use AnyEvent
926 in a module. This section is only of use to event loop authors who want 1214 in a module. This section is only of use to event loop authors who want
927 to provide AnyEvent compatibility. 1215 to provide AnyEvent compatibility.
982 warn "read: $input\n"; # output what has been read 1270 warn "read: $input\n"; # output what has been read
983 $cv->send if $input =~ /^q/i; # quit program if /^q/i 1271 $cv->send if $input =~ /^q/i; # quit program if /^q/i
984 }, 1272 },
985 ); 1273 );
986 1274
987 my $time_watcher; # can only be used once
988
989 sub new_timer {
990 $timer = AnyEvent->timer (after => 1, cb => sub { 1275 my $time_watcher = AnyEvent->timer (after => 1, interval => 1, cb => sub {
991 warn "timeout\n"; # print 'timeout' about every second 1276 warn "timeout\n"; # print 'timeout' at most every second
992 &new_timer; # and restart the time
993 });
994 } 1277 });
995
996 new_timer; # create first timer
997 1278
998 $cv->recv; # wait until user enters /^q/i 1279 $cv->recv; # wait until user enters /^q/i
999 1280
1000REAL-WORLD EXAMPLE 1281REAL-WORLD EXAMPLE
1001 Consider the Net::FCP module. It features (among others) the following 1282 Consider the Net::FCP module. It features (among others) the following
1073 1354
1074 The actual code goes further and collects all errors ("die"s, 1355 The actual code goes further and collects all errors ("die"s,
1075 exceptions) that occurred during request processing. The "result" method 1356 exceptions) that occurred during request processing. The "result" method
1076 detects whether an exception as thrown (it is stored inside the $txn 1357 detects whether an exception as thrown (it is stored inside the $txn
1077 object) and just throws the exception, which means connection errors and 1358 object) and just throws the exception, which means connection errors and
1078 other problems get reported tot he code that tries to use the result, 1359 other problems get reported to the code that tries to use the result,
1079 not in a random callback. 1360 not in a random callback.
1080 1361
1081 All of this enables the following usage styles: 1362 All of this enables the following usage styles:
1082 1363
1083 1. Blocking: 1364 1. Blocking:
1128 through AnyEvent. The benchmark creates a lot of timers (with a zero 1409 through AnyEvent. The benchmark creates a lot of timers (with a zero
1129 timeout) and I/O watchers (watching STDOUT, a pty, to become writable, 1410 timeout) and I/O watchers (watching STDOUT, a pty, to become writable,
1130 which it is), lets them fire exactly once and destroys them again. 1411 which it is), lets them fire exactly once and destroys them again.
1131 1412
1132 Source code for this benchmark is found as eg/bench in the AnyEvent 1413 Source code for this benchmark is found as eg/bench in the AnyEvent
1133 distribution. 1414 distribution. It uses the AE interface, which makes a real difference
1415 for the EV and Perl backends only.
1134 1416
1135 Explanation of the columns 1417 Explanation of the columns
1136 *watcher* is the number of event watchers created/destroyed. Since 1418 *watcher* is the number of event watchers created/destroyed. Since
1137 different event models feature vastly different performances, each event 1419 different event models feature vastly different performances, each event
1138 loop was given a number of watchers so that overall runtime is 1420 loop was given a number of watchers so that overall runtime is
1157 *destroy* is the time, in microseconds, that it takes to destroy a 1439 *destroy* is the time, in microseconds, that it takes to destroy a
1158 single watcher. 1440 single watcher.
1159 1441
1160 Results 1442 Results
1161 name watchers bytes create invoke destroy comment 1443 name watchers bytes create invoke destroy comment
1162 EV/EV 400000 224 0.47 0.35 0.27 EV native interface 1444 EV/EV 100000 223 0.47 0.43 0.27 EV native interface
1163 EV/Any 100000 224 2.88 0.34 0.27 EV + AnyEvent watchers 1445 EV/Any 100000 223 0.48 0.42 0.26 EV + AnyEvent watchers
1164 CoroEV/Any 100000 224 2.85 0.35 0.28 coroutines + Coro::Signal 1446 Coro::EV/Any 100000 223 0.47 0.42 0.26 coroutines + Coro::Signal
1165 Perl/Any 100000 452 4.13 0.73 0.95 pure perl implementation 1447 Perl/Any 100000 431 2.70 0.74 0.92 pure perl implementation
1166 Event/Event 16000 517 32.20 31.80 0.81 Event native interface 1448 Event/Event 16000 516 31.16 31.84 0.82 Event native interface
1167 Event/Any 16000 590 35.85 31.55 1.06 Event + AnyEvent watchers 1449 Event/Any 16000 1203 42.61 34.79 1.80 Event + AnyEvent watchers
1450 IOAsync/Any 16000 1911 41.92 27.45 16.81 via IO::Async::Loop::IO_Poll
1451 IOAsync/Any 16000 1726 40.69 26.37 15.25 via IO::Async::Loop::Epoll
1168 Glib/Any 16000 1357 102.33 12.31 51.00 quadratic behaviour 1452 Glib/Any 16000 1118 89.00 12.57 51.17 quadratic behaviour
1169 Tk/Any 2000 1860 27.20 66.31 14.00 SEGV with >> 2000 watchers 1453 Tk/Any 2000 1346 20.96 10.75 8.00 SEGV with >> 2000 watchers
1170 POE/Event 2000 6328 109.99 751.67 14.02 via POE::Loop::Event 1454 POE/Any 2000 6951 108.97 795.32 14.24 via POE::Loop::Event
1171 POE/Select 2000 6027 94.54 809.13 579.80 via POE::Loop::Select 1455 POE/Any 2000 6648 94.79 774.40 575.51 via POE::Loop::Select
1172 1456
1173 Discussion 1457 Discussion
1174 The benchmark does *not* measure scalability of the event loop very 1458 The benchmark does *not* measure scalability of the event loop very
1175 well. For example, a select-based event loop (such as the pure perl one) 1459 well. For example, a select-based event loop (such as the pure perl one)
1176 can never compete with an event loop that uses epoll when the number of 1460 can never compete with an event loop that uses epoll when the number of
1187 benchmark machine, handling an event takes roughly 1600 CPU cycles with 1471 benchmark machine, handling an event takes roughly 1600 CPU cycles with
1188 EV, 3100 CPU cycles with AnyEvent's pure perl loop and almost 3000000 1472 EV, 3100 CPU cycles with AnyEvent's pure perl loop and almost 3000000
1189 CPU cycles with POE. 1473 CPU cycles with POE.
1190 1474
1191 "EV" is the sole leader regarding speed and memory use, which are both 1475 "EV" is the sole leader regarding speed and memory use, which are both
1192 maximal/minimal, respectively. Even when going through AnyEvent, it uses 1476 maximal/minimal, respectively. When using the AE API there is zero
1477 overhead (when going through the AnyEvent API create is about 5-6 times
1478 slower, with other times being equal, so still uses far less memory than
1193 far less memory than any other event loop and is still faster than Event 1479 any other event loop and is still faster than Event natively).
1194 natively.
1195 1480
1196 The pure perl implementation is hit in a few sweet spots (both the 1481 The pure perl implementation is hit in a few sweet spots (both the
1197 constant timeout and the use of a single fd hit optimisations in the 1482 constant timeout and the use of a single fd hit optimisations in the
1198 perl interpreter and the backend itself). Nevertheless this shows that 1483 perl interpreter and the backend itself). Nevertheless this shows that
1199 it adds very little overhead in itself. Like any select-based backend 1484 it adds very little overhead in itself. Like any select-based backend
1201 few of them active), of course, but this was not subject of this 1486 few of them active), of course, but this was not subject of this
1202 benchmark. 1487 benchmark.
1203 1488
1204 The "Event" module has a relatively high setup and callback invocation 1489 The "Event" module has a relatively high setup and callback invocation
1205 cost, but overall scores in on the third place. 1490 cost, but overall scores in on the third place.
1491
1492 "IO::Async" performs admirably well, about on par with "Event", even
1493 when using its pure perl backend.
1206 1494
1207 "Glib"'s memory usage is quite a bit higher, but it features a faster 1495 "Glib"'s memory usage is quite a bit higher, but it features a faster
1208 callback invocation and overall ends up in the same class as "Event". 1496 callback invocation and overall ends up in the same class as "Event".
1209 However, Glib scales extremely badly, doubling the number of watchers 1497 However, Glib scales extremely badly, doubling the number of watchers
1210 increases the processing time by more than a factor of four, making it 1498 increases the processing time by more than a factor of four, making it
1266 In this benchmark, we use 10000 socket pairs (20000 sockets), of which 1554 In this benchmark, we use 10000 socket pairs (20000 sockets), of which
1267 100 (1%) are active. This mirrors the activity of large servers with 1555 100 (1%) are active. This mirrors the activity of large servers with
1268 many connections, most of which are idle at any one point in time. 1556 many connections, most of which are idle at any one point in time.
1269 1557
1270 Source code for this benchmark is found as eg/bench2 in the AnyEvent 1558 Source code for this benchmark is found as eg/bench2 in the AnyEvent
1271 distribution. 1559 distribution. It uses the AE interface, which makes a real difference
1560 for the EV and Perl backends only.
1272 1561
1273 Explanation of the columns 1562 Explanation of the columns
1274 *sockets* is the number of sockets, and twice the number of "servers" 1563 *sockets* is the number of sockets, and twice the number of "servers"
1275 (as each server has a read and write socket end). 1564 (as each server has a read and write socket end).
1276 1565
1281 single "request", that is, reading the token from the pipe and 1570 single "request", that is, reading the token from the pipe and
1282 forwarding it to another server. This includes deleting the old timeout 1571 forwarding it to another server. This includes deleting the old timeout
1283 and creating a new one that moves the timeout into the future. 1572 and creating a new one that moves the timeout into the future.
1284 1573
1285 Results 1574 Results
1286 name sockets create request 1575 name sockets create request
1287 EV 20000 69.01 11.16 1576 EV 20000 62.66 7.99
1288 Perl 20000 73.32 35.87 1577 Perl 20000 68.32 32.64
1289 Event 20000 212.62 257.32 1578 IOAsync 20000 174.06 101.15 epoll
1290 Glib 20000 651.16 1896.30 1579 IOAsync 20000 174.67 610.84 poll
1580 Event 20000 202.69 242.91
1581 Glib 20000 557.01 1689.52
1291 POE 20000 349.67 12317.24 uses POE::Loop::Event 1582 POE 20000 341.54 12086.32 uses POE::Loop::Event
1292 1583
1293 Discussion 1584 Discussion
1294 This benchmark *does* measure scalability and overall performance of the 1585 This benchmark *does* measure scalability and overall performance of the
1295 particular event loop. 1586 particular event loop.
1296 1587
1297 EV is again fastest. Since it is using epoll on my system, the setup 1588 EV is again fastest. Since it is using epoll on my system, the setup
1298 time is relatively high, though. 1589 time is relatively high, though.
1299 1590
1300 Perl surprisingly comes second. It is much faster than the C-based event 1591 Perl surprisingly comes second. It is much faster than the C-based event
1301 loops Event and Glib. 1592 loops Event and Glib.
1593
1594 IO::Async performs very well when using its epoll backend, and still
1595 quite good compared to Glib when using its pure perl backend.
1302 1596
1303 Event suffers from high setup time as well (look at its code and you 1597 Event suffers from high setup time as well (look at its code and you
1304 will understand why). Callback invocation also has a high overhead 1598 will understand why). Callback invocation also has a high overhead
1305 compared to the "$_->() for .."-style loop that the Perl event loop 1599 compared to the "$_->() for .."-style loop that the Perl event loop
1306 uses. Event uses select or poll in basically all documented 1600 uses. Event uses select or poll in basically all documented
1357 1651
1358 Summary 1652 Summary
1359 * C-based event loops perform very well with small number of watchers, 1653 * C-based event loops perform very well with small number of watchers,
1360 as the management overhead dominates. 1654 as the management overhead dominates.
1361 1655
1656 THE IO::Lambda BENCHMARK
1657 Recently I was told about the benchmark in the IO::Lambda manpage, which
1658 could be misinterpreted to make AnyEvent look bad. In fact, the
1659 benchmark simply compares IO::Lambda with POE, and IO::Lambda looks
1660 better (which shouldn't come as a surprise to anybody). As such, the
1661 benchmark is fine, and mostly shows that the AnyEvent backend from
1662 IO::Lambda isn't very optimal. But how would AnyEvent compare when used
1663 without the extra baggage? To explore this, I wrote the equivalent
1664 benchmark for AnyEvent.
1665
1666 The benchmark itself creates an echo-server, and then, for 500 times,
1667 connects to the echo server, sends a line, waits for the reply, and then
1668 creates the next connection. This is a rather bad benchmark, as it
1669 doesn't test the efficiency of the framework or much non-blocking I/O,
1670 but it is a benchmark nevertheless.
1671
1672 name runtime
1673 Lambda/select 0.330 sec
1674 + optimized 0.122 sec
1675 Lambda/AnyEvent 0.327 sec
1676 + optimized 0.138 sec
1677 Raw sockets/select 0.077 sec
1678 POE/select, components 0.662 sec
1679 POE/select, raw sockets 0.226 sec
1680 POE/select, optimized 0.404 sec
1681
1682 AnyEvent/select/nb 0.085 sec
1683 AnyEvent/EV/nb 0.068 sec
1684 +state machine 0.134 sec
1685
1686 The benchmark is also a bit unfair (my fault): the IO::Lambda/POE
1687 benchmarks actually make blocking connects and use 100% blocking I/O,
1688 defeating the purpose of an event-based solution. All of the newly
1689 written AnyEvent benchmarks use 100% non-blocking connects (using
1690 AnyEvent::Socket::tcp_connect and the asynchronous pure perl DNS
1691 resolver), so AnyEvent is at a disadvantage here, as non-blocking
1692 connects generally require a lot more bookkeeping and event handling
1693 than blocking connects (which involve a single syscall only).
1694
1695 The last AnyEvent benchmark additionally uses AnyEvent::Handle, which
1696 offers similar expressive power as POE and IO::Lambda, using
1697 conventional Perl syntax. This means that both the echo server and the
1698 client are 100% non-blocking, further placing it at a disadvantage.
1699
1700 As you can see, the AnyEvent + EV combination even beats the
1701 hand-optimised "raw sockets benchmark", while AnyEvent + its pure perl
1702 backend easily beats IO::Lambda and POE.
1703
1704 And even the 100% non-blocking version written using the high-level (and
1705 slow :) AnyEvent::Handle abstraction beats both POE and IO::Lambda
1706 higher level ("unoptimised") abstractions by a large margin, even though
1707 it does all of DNS, tcp-connect and socket I/O in a non-blocking way.
1708
1709 The two AnyEvent benchmarks programs can be found as eg/ae0.pl and
1710 eg/ae2.pl in the AnyEvent distribution, the remaining benchmarks are
1711 part of the IO::Lambda distribution and were used without any changes.
1712
1362SIGNALS 1713SIGNALS
1363 AnyEvent currently installs handlers for these signals: 1714 AnyEvent currently installs handlers for these signals:
1364 1715
1365 SIGCHLD 1716 SIGCHLD
1366 A handler for "SIGCHLD" is installed by AnyEvent's child watcher 1717 A handler for "SIGCHLD" is installed by AnyEvent's child watcher
1367 emulation for event loops that do not support them natively. Also, 1718 emulation for event loops that do not support them natively. Also,
1368 some event loops install a similar handler. 1719 some event loops install a similar handler.
1720
1721 Additionally, when AnyEvent is loaded and SIGCHLD is set to IGNORE,
1722 then AnyEvent will reset it to default, to avoid losing child exit
1723 statuses.
1369 1724
1370 SIGPIPE 1725 SIGPIPE
1371 A no-op handler is installed for "SIGPIPE" when $SIG{PIPE} is 1726 A no-op handler is installed for "SIGPIPE" when $SIG{PIPE} is
1372 "undef" when AnyEvent gets loaded. 1727 "undef" when AnyEvent gets loaded.
1373 1728
1381 it is that this way, the handler will be restored to defaults on 1736 it is that this way, the handler will be restored to defaults on
1382 exec. 1737 exec.
1383 1738
1384 Feel free to install your own handler, or reset it to defaults. 1739 Feel free to install your own handler, or reset it to defaults.
1385 1740
1741RECOMMENDED/OPTIONAL MODULES
1742 One of AnyEvent's main goals is to be 100% Pure-Perl(tm): only perl (and
1743 it's built-in modules) are required to use it.
1744
1745 That does not mean that AnyEvent won't take advantage of some additional
1746 modules if they are installed.
1747
1748 This section explains which additional modules will be used, and how
1749 they affect AnyEvent's operation.
1750
1751 Async::Interrupt
1752 This slightly arcane module is used to implement fast signal
1753 handling: To my knowledge, there is no way to do completely
1754 race-free and quick signal handling in pure perl. To ensure that
1755 signals still get delivered, AnyEvent will start an interval timer
1756 to wake up perl (and catch the signals) with some delay (default is
1757 10 seconds, look for $AnyEvent::MAX_SIGNAL_LATENCY).
1758
1759 If this module is available, then it will be used to implement
1760 signal catching, which means that signals will not be delayed, and
1761 the event loop will not be interrupted regularly, which is more
1762 efficient (and good for battery life on laptops).
1763
1764 This affects not just the pure-perl event loop, but also other event
1765 loops that have no signal handling on their own (e.g. Glib, Tk, Qt).
1766
1767 Some event loops (POE, Event, Event::Lib) offer signal watchers
1768 natively, and either employ their own workarounds (POE) or use
1769 AnyEvent's workaround (using $AnyEvent::MAX_SIGNAL_LATENCY).
1770 Installing Async::Interrupt does nothing for those backends.
1771
1772 EV This module isn't really "optional", as it is simply one of the
1773 backend event loops that AnyEvent can use. However, it is simply the
1774 best event loop available in terms of features, speed and stability:
1775 It supports the AnyEvent API optimally, implements all the watcher
1776 types in XS, does automatic timer adjustments even when no monotonic
1777 clock is available, can take avdantage of advanced kernel interfaces
1778 such as "epoll" and "kqueue", and is the fastest backend *by far*.
1779 You can even embed Glib/Gtk2 in it (or vice versa, see EV::Glib and
1780 Glib::EV).
1781
1782 If you only use backends that rely on another event loop (e.g.
1783 "Tk"), then this module will do nothing for you.
1784
1785 Guard
1786 The guard module, when used, will be used to implement
1787 "AnyEvent::Util::guard". This speeds up guards considerably (and
1788 uses a lot less memory), but otherwise doesn't affect guard
1789 operation much. It is purely used for performance.
1790
1791 JSON and JSON::XS
1792 One of these modules is required when you want to read or write JSON
1793 data via AnyEvent::Handle. JSON is also written in pure-perl, but
1794 can take advantage of the ultra-high-speed JSON::XS module when it
1795 is installed.
1796
1797 Net::SSLeay
1798 Implementing TLS/SSL in Perl is certainly interesting, but not very
1799 worthwhile: If this module is installed, then AnyEvent::Handle (with
1800 the help of AnyEvent::TLS), gains the ability to do TLS/SSL.
1801
1802 Time::HiRes
1803 This module is part of perl since release 5.008. It will be used
1804 when the chosen event library does not come with a timing source on
1805 it's own. The pure-perl event loop (AnyEvent::Impl::Perl) will
1806 additionally use it to try to use a monotonic clock for timing
1807 stability.
1808
1386FORK 1809FORK
1387 Most event libraries are not fork-safe. The ones who are usually are 1810 Most event libraries are not fork-safe. The ones who are usually are
1388 because they rely on inefficient but fork-safe "select" or "poll" calls. 1811 because they rely on inefficient but fork-safe "select" or "poll" calls
1389 Only EV is fully fork-aware. 1812 - higher performance APIs such as BSD's kqueue or the dreaded Linux
1813 epoll are usually badly thought-out hacks that are incompatible with
1814 fork in one way or another. Only EV is fully fork-aware and ensures that
1815 you continue event-processing in both parent and child (or both, if you
1816 know what you are doing).
1817
1818 This means that, in general, you cannot fork and do event processing in
1819 the child if the event library was initialised before the fork (which
1820 usually happens when the first AnyEvent watcher is created, or the
1821 library is loaded).
1390 1822
1391 If you have to fork, you must either do so *before* creating your first 1823 If you have to fork, you must either do so *before* creating your first
1392 watcher OR you must not use AnyEvent at all in the child. 1824 watcher OR you must not use AnyEvent at all in the child OR you must do
1825 something completely out of the scope of AnyEvent.
1826
1827 The problem of doing event processing in the parent *and* the child is
1828 much more complicated: even for backends that *are* fork-aware or
1829 fork-safe, their behaviour is not usually what you want: fork clones all
1830 watchers, that means all timers, I/O watchers etc. are active in both
1831 parent and child, which is almost never what you want. USing "exec" to
1832 start worker children from some kind of manage rprocess is usually
1833 preferred, because it is much easier and cleaner, at the expense of
1834 having to have another binary.
1393 1835
1394SECURITY CONSIDERATIONS 1836SECURITY CONSIDERATIONS
1395 AnyEvent can be forced to load any event model via 1837 AnyEvent can be forced to load any event model via
1396 $ENV{PERL_ANYEVENT_MODEL}. While this cannot (to my knowledge) be used 1838 $ENV{PERL_ANYEVENT_MODEL}. While this cannot (to my knowledge) be used
1397 to execute arbitrary code or directly gain access, it can easily be used 1839 to execute arbitrary code or directly gain access, it can easily be used
1407 use AnyEvent; 1849 use AnyEvent;
1408 1850
1409 Similar considerations apply to $ENV{PERL_ANYEVENT_VERBOSE}, as that can 1851 Similar considerations apply to $ENV{PERL_ANYEVENT_VERBOSE}, as that can
1410 be used to probe what backend is used and gain other information (which 1852 be used to probe what backend is used and gain other information (which
1411 is probably even less useful to an attacker than PERL_ANYEVENT_MODEL), 1853 is probably even less useful to an attacker than PERL_ANYEVENT_MODEL),
1412 and $ENV{PERL_ANYEGENT_STRICT}. 1854 and $ENV{PERL_ANYEVENT_STRICT}.
1855
1856 Note that AnyEvent will remove *all* environment variables starting with
1857 "PERL_ANYEVENT_" from %ENV when it is loaded while taint mode is
1858 enabled.
1413 1859
1414BUGS 1860BUGS
1415 Perl 5.8 has numerous memleaks that sometimes hit this module and are 1861 Perl 5.8 has numerous memleaks that sometimes hit this module and are
1416 hard to work around. If you suffer from memleaks, first upgrade to Perl 1862 hard to work around. If you suffer from memleaks, first upgrade to Perl
1417 5.10 and check wether the leaks still show up. (Perl 5.10.0 has other 1863 5.10 and check wether the leaks still show up. (Perl 5.10.0 has other
1424 Event modules: EV, EV::Glib, Glib::EV, Event, Glib::Event, Glib, Tk, 1870 Event modules: EV, EV::Glib, Glib::EV, Event, Glib::Event, Glib, Tk,
1425 Event::Lib, Qt, POE. 1871 Event::Lib, Qt, POE.
1426 1872
1427 Implementations: AnyEvent::Impl::EV, AnyEvent::Impl::Event, 1873 Implementations: AnyEvent::Impl::EV, AnyEvent::Impl::Event,
1428 AnyEvent::Impl::Glib, AnyEvent::Impl::Tk, AnyEvent::Impl::Perl, 1874 AnyEvent::Impl::Glib, AnyEvent::Impl::Tk, AnyEvent::Impl::Perl,
1429 AnyEvent::Impl::EventLib, AnyEvent::Impl::Qt, AnyEvent::Impl::POE. 1875 AnyEvent::Impl::EventLib, AnyEvent::Impl::Qt, AnyEvent::Impl::POE,
1876 AnyEvent::Impl::IOAsync, Anyevent::Impl::Irssi.
1430 1877
1431 Non-blocking file handles, sockets, TCP clients and servers: 1878 Non-blocking file handles, sockets, TCP clients and servers:
1432 AnyEvent::Handle, AnyEvent::Socket. 1879 AnyEvent::Handle, AnyEvent::Socket, AnyEvent::TLS.
1433 1880
1434 Asynchronous DNS: AnyEvent::DNS. 1881 Asynchronous DNS: AnyEvent::DNS.
1435 1882
1436 Coroutine support: Coro, Coro::AnyEvent, Coro::EV, Coro::Event, 1883 Coroutine support: Coro, Coro::AnyEvent, Coro::EV, Coro::Event,
1437 1884
1438 Nontrivial usage examples: Net::FCP, Net::XMPP2, AnyEvent::DNS. 1885 Nontrivial usage examples: AnyEvent::GPSD, AnyEvent::XMPP,
1886 AnyEvent::HTTP.
1439 1887
1440AUTHOR 1888AUTHOR
1441 Marc Lehmann <schmorp@schmorp.de> 1889 Marc Lehmann <schmorp@schmorp.de>
1442 http://home.schmorp.de/ 1890 http://home.schmorp.de/
1443 1891

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines