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.47 by root, Mon Jul 20 22:39:57 2009 UTC

1NAME 1NAME
2 AnyEvent - provide framework for multiple event loops 2 AnyEvent - events independent of event loop implementation
3 3
4 EV, Event, Glib, Tk, Perl, Event::Lib, Qt, POE - various supported event 4 EV, Event, Glib, Tk, Perl, Event::Lib, Qt and POE are various supported
5 loops 5 event loops.
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 { ... });
11 12
13 # one-shot or repeating timers
12 my $w = AnyEvent->timer (after => $seconds, cb => sub { ... }); 14 my $w = AnyEvent->timer (after => $seconds, cb => sub { ... });
13 my $w = AnyEvent->timer (after => $seconds, interval => $seconds, cb => ... 15 my $w = AnyEvent->timer (after => $seconds, interval => $seconds, cb => ...
14 16
15 print AnyEvent->now; # prints current event loop time 17 print AnyEvent->now; # prints current event loop time
16 print AnyEvent->time; # think Time::HiRes::time or simply CORE::time. 18 print AnyEvent->time; # think Time::HiRes::time or simply CORE::time.
17 19
20 # POSIX signal
18 my $w = AnyEvent->signal (signal => "TERM", cb => sub { ... }); 21 my $w = AnyEvent->signal (signal => "TERM", cb => sub { ... });
19 22
23 # child process exit
20 my $w = AnyEvent->child (pid => $pid, cb => sub { 24 my $w = AnyEvent->child (pid => $pid, cb => sub {
21 my ($pid, $status) = @_; 25 my ($pid, $status) = @_;
22 ... 26 ...
23 }); 27 });
28
29 # called when event loop idle (if applicable)
30 my $w = AnyEvent->idle (cb => sub { ... });
24 31
25 my $w = AnyEvent->condvar; # stores whether a condition was flagged 32 my $w = AnyEvent->condvar; # stores whether a condition was flagged
26 $w->send; # wake up current and all future recv's 33 $w->send; # wake up current and all future recv's
27 $w->recv; # enters "main loop" till $condvar gets ->send 34 $w->recv; # enters "main loop" till $condvar gets ->send
28 # use a condvar in callback mode: 35 # use a condvar in callback mode:
30 37
31INTRODUCTION/TUTORIAL 38INTRODUCTION/TUTORIAL
32 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
33 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
34 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 Respository, at <http://anyevent.schmorp.de>, for more info.
35 49
36WHY YOU SHOULD USE THIS MODULE (OR NOT) 50WHY YOU SHOULD USE THIS MODULE (OR NOT)
37 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
38 nowadays. So what is different about AnyEvent? 52 nowadays. So what is different about AnyEvent?
39 53
162 176
163 I/O WATCHERS 177 I/O WATCHERS
164 You can create an I/O watcher by calling the "AnyEvent->io" method with 178 You can create an I/O watcher by calling the "AnyEvent->io" method with
165 the following mandatory key-value pairs as arguments: 179 the following mandatory key-value pairs as arguments:
166 180
167 "fh" is the Perl *file handle* (*not* file descriptor) to watch for 181 "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 182 events (AnyEvent might or might not keep a reference to this file
169 handle). Note that only file handles pointing to things for which 183 handle). Note that only file handles pointing to things for which
170 non-blocking operation makes sense are allowed. This includes sockets, 184 non-blocking operation makes sense are allowed. This includes sockets,
171 most character devices, pipes, fifos and so on, but not for example 185 most character devices, pipes, fifos and so on, but not for example
172 files or block devices. 186 files or block devices.
343 invocation, and callback invocation will be synchronous. Synchronous 357 invocation, and callback invocation will be synchronous. Synchronous
344 means that it might take a while until the signal gets handled by the 358 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. 359 process, but it is guaranteed not to interrupt any other callbacks.
346 360
347 The main advantage of using these watchers is that you can share a 361 The main advantage of using these watchers is that you can share a
348 signal between multiple watchers. 362 signal between multiple watchers, and AnyEvent will ensure that signals
363 will not interrupt your program at bad times.
349 364
350 This watcher might use %SIG, so programs overwriting those signals 365 This watcher might use %SIG (depending on the event loop used), so
351 directly will likely not work correctly. 366 programs overwriting those signals directly will likely not work
367 correctly.
352 368
353 Example: exit on SIGINT 369 Example: exit on SIGINT
354 370
355 my $w = AnyEvent->signal (signal => "INT", cb => sub { exit 1 }); 371 my $w = AnyEvent->signal (signal => "INT", cb => sub { exit 1 });
372
373 Signal Races, Delays and Workarounds
374 Many event loops (e.g. Glib, Tk, Qt, IO::Async) do not support attaching
375 callbacks to signals in a generic way, which is a pity, as you cannot do
376 race-free signal handling in perl. AnyEvent will try to do it's best,
377 but in some cases, signals will be delayed. The maximum time a signal
378 might be delayed is specified in $AnyEvent::MAX_SIGNAL_LATENCY (default:
379 10 seconds). This variable can be changed only before the first signal
380 watcher is created, and should be left alone otherwise. Higher values
381 will cause fewer spurious wake-ups, which is better for power and CPU
382 saving. All these problems can be avoided by installing the optional
383 Async::Interrupt module. This will not work with inherently broken event
384 loops such as Event or Event::Lib (and not with POE currently, as POE
385 does it's own workaround with one-second latency). With those, you just
386 have to suffer the delays.
356 387
357 CHILD PROCESS WATCHERS 388 CHILD PROCESS WATCHERS
358 You can also watch on a child process exit and catch its exit status. 389 You can also watch on a child process exit and catch its exit status.
359 390
360 The child process is specified by the "pid" argument (if set to 0, it 391 The child process is specified by the "pid" argument (if set to 0, it
373 404
374 There is a slight catch to child watchers, however: you usually start 405 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 406 them *after* the child process was created, and this means the process
376 could have exited already (and no SIGCHLD will be sent anymore). 407 could have exited already (and no SIGCHLD will be sent anymore).
377 408
378 Not all event models handle this correctly (POE doesn't), but even for 409 Not all event models handle this correctly (neither POE nor IO::Async
410 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 411 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 412 before the process exits (i.e. before you fork in the first place).
381 place). 413 AnyEvent's pure perl event loop handles all cases correctly regardless
414 of when you start the watcher.
382 415
383 This means you cannot create a child watcher as the very first thing in 416 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 417 an AnyEvent program, you *have* to create at least one watcher before
385 you "fork" the child (alternatively, you can call "AnyEvent::detect"). 418 you "fork" the child (alternatively, you can call "AnyEvent::detect").
386 419
420 As most event loops do not support waiting for child events, they will
421 be emulated by AnyEvent in most cases, in which the latency and race
422 problems mentioned in the description of signal watchers apply.
423
387 Example: fork a process and wait for it 424 Example: fork a process and wait for it
388 425
389 my $done = AnyEvent->condvar; 426 my $done = AnyEvent->condvar;
390 427
391 my $pid = fork or exit 5; 428 my $pid = fork or exit 5;
392 429
393 my $w = AnyEvent->child ( 430 my $w = AnyEvent->child (
394 pid => $pid, 431 pid => $pid,
395 cb => sub { 432 cb => sub {
396 my ($pid, $status) = @_; 433 my ($pid, $status) = @_;
397 warn "pid $pid exited with status $status"; 434 warn "pid $pid exited with status $status";
398 $done->send; 435 $done->send;
399 }, 436 },
400 ); 437 );
401 438
402 # do something else, then wait for process exit 439 # do something else, then wait for process exit
403 $done->recv; 440 $done->recv;
441
442 IDLE WATCHERS
443 Sometimes there is a need to do something, but it is not so important to
444 do it instantly, but only when there is nothing better to do. This
445 "nothing better to do" is usually defined to be "no other events need
446 attention by the event loop".
447
448 Idle watchers ideally get invoked when the event loop has nothing better
449 to do, just before it would block the process to wait for new events.
450 Instead of blocking, the idle watcher is invoked.
451
452 Most event loops unfortunately do not really support idle watchers (only
453 EV, Event and Glib do it in a usable fashion) - for the rest, AnyEvent
454 will simply call the callback "from time to time".
455
456 Example: read lines from STDIN, but only process them when the program
457 is otherwise idle:
458
459 my @lines; # read data
460 my $idle_w;
461 my $io_w = AnyEvent->io (fh => \*STDIN, poll => 'r', cb => sub {
462 push @lines, scalar <STDIN>;
463
464 # start an idle watcher, if not already done
465 $idle_w ||= AnyEvent->idle (cb => sub {
466 # handle only one line, when there are lines left
467 if (my $line = shift @lines) {
468 print "handled when idle: $line";
469 } else {
470 # otherwise disable the idle watcher again
471 undef $idle_w;
472 }
473 });
474 });
404 475
405 CONDITION VARIABLES 476 CONDITION VARIABLES
406 If you are familiar with some event loops you will know that all of them 477 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 478 require you to run some blocking "loop", "run" or similar function that
408 will actively watch for new events and call your callbacks. 479 will actively watch for new events and call your callbacks.
409 480
410 AnyEvent is different, it expects somebody else to run the event loop 481 AnyEvent is slightly different: it expects somebody else to run the
411 and will only block when necessary (usually when told by the user). 482 event loop and will only block when necessary (usually when told by the
483 user).
412 484
413 The instrument to do that is called a "condition variable", so called 485 The instrument to do that is called a "condition variable", so called
414 because they represent a condition that must become true. 486 because they represent a condition that must become true.
415 487
488 Now is probably a good time to look at the examples further below.
489
416 Condition variables can be created by calling the "AnyEvent->condvar" 490 Condition variables can be created by calling the "AnyEvent->condvar"
417 method, usually without arguments. The only argument pair allowed is 491 method, usually without arguments. The only argument pair allowed is
418
419 "cb", which specifies a callback to be called when the condition 492 "cb", which specifies a callback to be called when the condition
420 variable becomes true, with the condition variable as the first argument 493 variable becomes true, with the condition variable as the first argument
421 (but not the results). 494 (but not the results).
422 495
423 After creation, the condition variable is "false" until it becomes 496 After creation, the condition variable is "false" until it becomes
428 Condition variables are similar to callbacks, except that you can 501 Condition variables are similar to callbacks, except that you can
429 optionally wait for them. They can also be called merge points - points 502 optionally wait for them. They can also be called merge points - points
430 in time where multiple outstanding events have been processed. And yet 503 in time where multiple outstanding events have been processed. And yet
431 another way to call them is transactions - each condition variable can 504 another way to call them is transactions - each condition variable can
432 be used to represent a transaction, which finishes at some point and 505 be used to represent a transaction, which finishes at some point and
433 delivers a result. 506 delivers a result. And yet some people know them as "futures" - a
507 promise to compute/deliver something that you can wait for.
434 508
435 Condition variables are very useful to signal that something has 509 Condition variables are very useful to signal that something has
436 finished, for example, if you write a module that does asynchronous http 510 finished, for example, if you write a module that does asynchronous http
437 requests, then a condition variable would be the ideal candidate to 511 requests, then a condition variable would be the ideal candidate to
438 signal the availability of results. The user can either act when the 512 signal the availability of results. The user can either act when the
472 after => 1, 546 after => 1,
473 cb => sub { $result_ready->send }, 547 cb => sub { $result_ready->send },
474 ); 548 );
475 549
476 # this "blocks" (while handling events) till the callback 550 # this "blocks" (while handling events) till the callback
477 # calls send 551 # calls -<send
478 $result_ready->recv; 552 $result_ready->recv;
479 553
480 Example: wait for a timer, but take advantage of the fact that condition 554 Example: wait for a timer, but take advantage of the fact that condition
481 variables are also code references. 555 variables are also callable directly.
482 556
483 my $done = AnyEvent->condvar; 557 my $done = AnyEvent->condvar;
484 my $delay = AnyEvent->timer (after => 5, cb => $done); 558 my $delay = AnyEvent->timer (after => 5, cb => $done);
485 $done->recv; 559 $done->recv;
486 560
492 566
493 ... 567 ...
494 568
495 my @info = $couchdb->info->recv; 569 my @info = $couchdb->info->recv;
496 570
497 And this is how you would just ste a callback to be called whenever the 571 And this is how you would just set a callback to be called whenever the
498 results are available: 572 results are available:
499 573
500 $couchdb->info->cb (sub { 574 $couchdb->info->cb (sub {
501 my @info = $_[0]->recv; 575 my @info = $_[0]->recv;
502 }); 576 });
517 591
518 Any arguments passed to the "send" call will be returned by all 592 Any arguments passed to the "send" call will be returned by all
519 future "->recv" calls. 593 future "->recv" calls.
520 594
521 Condition variables are overloaded so one can call them directly (as 595 Condition variables are overloaded so one can call them directly (as
522 a code reference). Calling them directly is the same as calling 596 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 597 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 598
530 $cv->croak ($error) 599 $cv->croak ($error)
531 Similar to send, but causes all call's to "->recv" to invoke 600 Similar to send, but causes all call's to "->recv" to invoke
532 "Carp::croak" with the given error message/object/scalar. 601 "Carp::croak" with the given error message/object/scalar.
533 602
534 This can be used to signal any errors to the condition variable 603 This can be used to signal any errors to the condition variable
535 user/consumer. 604 user/consumer. Doing it this way instead of calling "croak" directly
605 delays the error detetcion, but has the overwhelmign advantage that
606 it diagnoses the error at the place where the result is expected,
607 and not deep in some event clalback without connection to the actual
608 code causing the problem.
536 609
537 $cv->begin ([group callback]) 610 $cv->begin ([group callback])
538 $cv->end 611 $cv->end
539 These two methods are EXPERIMENTAL and MIGHT CHANGE.
540
541 These two methods can be used to combine many transactions/events 612 These two methods can be used to combine many transactions/events
542 into one. For example, a function that pings many hosts in parallel 613 into one. For example, a function that pings many hosts in parallel
543 might want to use a condition variable for the whole process. 614 might want to use a condition variable for the whole process.
544 615
545 Every call to "->begin" will increment a counter, and every call to 616 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 617 "->end" will decrement it. If the counter reaches 0 in "->end", the
547 (last) callback passed to "begin" will be executed. That callback is 618 (last) callback passed to "begin" will be executed. That callback is
548 *supposed* to call "->send", but that is not required. If no 619 *supposed* to call "->send", but that is not required. If no
549 callback was set, "send" will be called without any arguments. 620 callback was set, "send" will be called without any arguments.
550 621
551 Let's clarify this with the ping example: 622 You can think of "$cv->send" giving you an OR condition (one call
623 sends), while "$cv->begin" and "$cv->end" giving you an AND
624 condition (all "begin" calls must be "end"'ed before the condvar
625 sends).
626
627 Let's start with a simple example: you have two I/O watchers (for
628 example, STDOUT and STDERR for a program), and you want to wait for
629 both streams to close before activating a condvar:
630
631 my $cv = AnyEvent->condvar;
632
633 $cv->begin; # first watcher
634 my $w1 = AnyEvent->io (fh => $fh1, cb => sub {
635 defined sysread $fh1, my $buf, 4096
636 or $cv->end;
637 });
638
639 $cv->begin; # second watcher
640 my $w2 = AnyEvent->io (fh => $fh2, cb => sub {
641 defined sysread $fh2, my $buf, 4096
642 or $cv->end;
643 });
644
645 $cv->recv;
646
647 This works because for every event source (EOF on file handle),
648 there is one call to "begin", so the condvar waits for all calls to
649 "end" before sending.
650
651 The ping example mentioned above is slightly more complicated, as
652 the there are results to be passwd back, and the number of tasks
653 that are begung can potentially be zero:
552 654
553 my $cv = AnyEvent->condvar; 655 my $cv = AnyEvent->condvar;
554 656
555 my %result; 657 my %result;
556 $cv->begin (sub { $cv->send (\%result) }); 658 $cv->begin (sub { $cv->send (\%result) });
576 the loop, which serves two important purposes: first, it sets the 678 the loop, which serves two important purposes: first, it sets the
577 callback to be called once the counter reaches 0, and second, it 679 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 680 ensures that "send" is called even when "no" hosts are being pinged
579 (the loop doesn't execute once). 681 (the loop doesn't execute once).
580 682
581 This is the general pattern when you "fan out" into multiple 683 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 684 potentially none) subrequests: use an outer "begin"/"end" pair to
583 ensure "end" is called at least once, and then, for each subrequest 685 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 686 for each subrequest you start, call "begin" and for each subrequest
585 "end". 687 you finish, call "end".
586 688
587 METHODS FOR CONSUMERS 689 METHODS FOR CONSUMERS
588 These methods should only be used by the consuming side, i.e. the code 690 These methods should only be used by the consuming side, i.e. the code
589 awaits the condition. 691 awaits the condition.
590 692
599 function will call "croak". 701 function will call "croak".
600 702
601 In list context, all parameters passed to "send" will be returned, 703 In list context, all parameters passed to "send" will be returned,
602 in scalar context only the first one will be returned. 704 in scalar context only the first one will be returned.
603 705
706 Note that doing a blocking wait in a callback is not supported by
707 any event loop, that is, recursive invocation of a blocking "->recv"
708 is not allowed, and the "recv" call will "croak" if such a condition
709 is detected. This condition can be slightly loosened by using
710 Coro::AnyEvent, which allows you to do a blocking "->recv" from any
711 thread that doesn't run the event loop itself.
712
604 Not all event models support a blocking wait - some die in that case 713 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 714 (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 715 using this from a module, never require a blocking wait*. Instead,
607 the caller decide whether the call will block or not (for example, 716 let the caller decide whether the call will block or not (for
608 by coupling condition variables with some kind of request results 717 example, by coupling condition variables with some kind of request
609 and supporting callbacks so the caller knows that getting the result 718 results and supporting callbacks so the caller knows that getting
610 will not block, while still supporting blocking waits if the caller 719 the result will not block, while still supporting blocking waits if
611 so desires). 720 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 721
624 You can ensure that "-recv" never blocks by setting a callback and 722 You can ensure that "-recv" never blocks by setting a callback and
625 only calling "->recv" from within that callback (or at a later 723 only calling "->recv" from within that callback (or at a later
626 time). This will work even when the event loop does not support 724 time). This will work even when the event loop does not support
627 blocking waits otherwise. 725 blocking waits otherwise.
637 The callback will be called when the condition becomes "true", i.e. 735 The callback will be called when the condition becomes "true", i.e.
638 when "send" or "croak" are called, with the only argument being the 736 when "send" or "croak" are called, with the only argument being the
639 condition variable itself. Calling "recv" inside the callback or at 737 condition variable itself. Calling "recv" inside the callback or at
640 any later time is guaranteed not to block. 738 any later time is guaranteed not to block.
641 739
740SUPPORTED EVENT LOOPS/BACKENDS
741 The available backend classes are (every class has its own manpage):
742
743 Backends that are autoprobed when no other event loop can be found.
744 EV is the preferred backend when no other event loop seems to be in
745 use. If EV is not installed, then AnyEvent will try Event, and,
746 failing that, will fall back to its own pure-perl implementation,
747 which is available everywhere as it comes with AnyEvent itself.
748
749 AnyEvent::Impl::EV based on EV (interface to libev, best choice).
750 AnyEvent::Impl::Event based on Event, very stable, few glitches.
751 AnyEvent::Impl::Perl pure-perl implementation, fast and portable.
752
753 Backends that are transparently being picked up when they are used.
754 These will be used when they are currently loaded when the first
755 watcher is created, in which case it is assumed that the application
756 is using them. This means that AnyEvent will automatically pick the
757 right backend when the main program loads an event module before
758 anything starts to create watchers. Nothing special needs to be done
759 by the main program.
760
761 AnyEvent::Impl::Glib based on Glib, slow but very stable.
762 AnyEvent::Impl::Tk based on Tk, very broken.
763 AnyEvent::Impl::EventLib based on Event::Lib, leaks memory and worse.
764 AnyEvent::Impl::POE based on POE, very slow, some limitations.
765
766 Backends with special needs.
767 Qt requires the Qt::Application to be instantiated first, but will
768 otherwise be picked up automatically. As long as the main program
769 instantiates the application before any AnyEvent watchers are
770 created, everything should just work.
771
772 AnyEvent::Impl::Qt based on Qt.
773
774 Support for IO::Async can only be partial, as it is too broken and
775 architecturally limited to even support the AnyEvent API. It also is
776 the only event loop that needs the loop to be set explicitly, so it
777 can only be used by a main program knowing about AnyEvent. See
778 AnyEvent::Impl::Async for the gory details.
779
780 AnyEvent::Impl::IOAsync based on IO::Async, cannot be autoprobed.
781
782 Event loops that are indirectly supported via other backends.
783 Some event loops can be supported via other modules:
784
785 There is no direct support for WxWidgets (Wx) or Prima.
786
787 WxWidgets has no support for watching file handles. However, you can
788 use WxWidgets through the POE adaptor, as POE has a Wx backend that
789 simply polls 20 times per second, which was considered to be too
790 horrible to even consider for AnyEvent.
791
792 Prima is not supported as nobody seems to be using it, but it has a
793 POE backend, so it can be supported through POE.
794
795 AnyEvent knows about both Prima and Wx, however, and will try to
796 load POE when detecting them, in the hope that POE will pick them
797 up, in which case everything will be automatic.
798
642GLOBAL VARIABLES AND FUNCTIONS 799GLOBAL VARIABLES AND FUNCTIONS
800 These are not normally required to use AnyEvent, but can be useful to
801 write AnyEvent extension modules.
802
643 $AnyEvent::MODEL 803 $AnyEvent::MODEL
644 Contains "undef" until the first watcher is being created. Then it 804 Contains "undef" until the first watcher is being created, before
805 the backend has been autodetected.
806
645 contains the event model that is being used, which is the name of 807 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 808 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 809 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*). 810 other class in the case AnyEvent has been extended at runtime (e.g.
649 811 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 812
671 AnyEvent::detect 813 AnyEvent::detect
672 Returns $AnyEvent::MODEL, forcing autodetection of the event model 814 Returns $AnyEvent::MODEL, forcing autodetection of the event model
673 if necessary. You should only call this function right before you 815 if necessary. You should only call this function right before you
674 would have created an AnyEvent watcher anyway, that is, as late as 816 would have created an AnyEvent watcher anyway, that is, as late as
675 possible at runtime. 817 possible at runtime, and not e.g. while initialising of your module.
818
819 If you need to do some initialisation before AnyEvent watchers are
820 created, use "post_detect".
676 821
677 $guard = AnyEvent::post_detect { BLOCK } 822 $guard = AnyEvent::post_detect { BLOCK }
678 Arranges for the code block to be executed as soon as the event 823 Arranges for the code block to be executed as soon as the event
679 model is autodetected (or immediately if this has already happened). 824 model is autodetected (or immediately if this has already happened).
825
826 The block will be executed *after* the actual backend has been
827 detected ($AnyEvent::MODEL is set), but *before* any watchers have
828 been created, so it is possible to e.g. patch @AnyEvent::ISA or do
829 other initialisations - see the sources of AnyEvent::Strict or
830 AnyEvent::AIO to see how this is used.
831
832 The most common usage is to create some global watchers, without
833 forcing event module detection too early, for example, AnyEvent::AIO
834 creates and installs the global IO::AIO watcher in a "post_detect"
835 block to avoid autodetecting the event module at load time.
680 836
681 If called in scalar or list context, then it creates and returns an 837 If called in scalar or list context, then it creates and returns an
682 object that automatically removes the callback again when it is 838 object that automatically removes the callback again when it is
683 destroyed. See Coro::BDB for a case where this is useful. 839 destroyed. See Coro::BDB for a case where this is useful.
684 840
686 If there are any code references in this array (you can "push" to it 842 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 843 before or after loading AnyEvent), then they will called directly
688 after the event loop has been chosen. 844 after the event loop has been chosen.
689 845
690 You should check $AnyEvent::MODEL before adding to this array, 846 You should check $AnyEvent::MODEL before adding to this array,
691 though: if it contains a true value then the event loop has already 847 though: if it is defined then the event loop has already been
692 been detected, and the array will be ignored. 848 detected, and the array will be ignored.
693 849
694 Best use "AnyEvent::post_detect { BLOCK }" instead. 850 Best use "AnyEvent::post_detect { BLOCK }" when your application
851 allows it,as it takes care of these details.
852
853 This variable is mainly useful for modules that can do something
854 useful when AnyEvent is used and thus want to know when it is
855 initialised, but do not need to even load it by default. This array
856 provides the means to hook into AnyEvent passively, without loading
857 it.
695 858
696WHAT TO DO IN A MODULE 859WHAT TO DO IN A MODULE
697 As a module author, you should "use AnyEvent" and call AnyEvent methods 860 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. 861 freely, but you should not load a specific event module or rely on it.
699 862
750 variable somewhere, waiting for it, and sending it when the program 913 variable somewhere, waiting for it, and sending it when the program
751 should exit cleanly. 914 should exit cleanly.
752 915
753OTHER MODULES 916OTHER MODULES
754 The following is a non-exhaustive list of additional modules that use 917 The following is a non-exhaustive list of additional modules that use
755 AnyEvent and can therefore be mixed easily with other AnyEvent modules 918 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 919 AnyEvent modules and other event loops in the same program. Some of the
757 available via CPAN. 920 modules come with AnyEvent, most are available via CPAN.
758 921
759 AnyEvent::Util 922 AnyEvent::Util
760 Contains various utility functions that replace often-used but 923 Contains various utility functions that replace often-used but
761 blocking functions such as "inet_aton" by event-/callback-based 924 blocking functions such as "inet_aton" by event-/callback-based
762 versions. 925 versions.
768 more. 931 more.
769 932
770 AnyEvent::Handle 933 AnyEvent::Handle
771 Provide read and write buffers, manages watchers for reads and 934 Provide read and write buffers, manages watchers for reads and
772 writes, supports raw and formatted I/O, I/O queued and fully 935 writes, supports raw and formatted I/O, I/O queued and fully
773 transparent and non-blocking SSL/TLS. 936 transparent and non-blocking SSL/TLS (via AnyEvent::TLS.
774 937
775 AnyEvent::DNS 938 AnyEvent::DNS
776 Provides rich asynchronous DNS resolver capabilities. 939 Provides rich asynchronous DNS resolver capabilities.
777 940
778 AnyEvent::HTTP 941 AnyEvent::HTTP
799 962
800 AnyEvent::GPSD 963 AnyEvent::GPSD
801 A non-blocking interface to gpsd, a daemon delivering GPS 964 A non-blocking interface to gpsd, a daemon delivering GPS
802 information. 965 information.
803 966
967 AnyEvent::IRC
968 AnyEvent based IRC client module family (replacing the older
969 Net::IRC3).
970
971 AnyEvent::XMPP
972 AnyEvent based XMPP (Jabber protocol) module family (replacing the
973 older Net::XMPP2>.
974
804 AnyEvent::IGS 975 AnyEvent::IGS
805 A non-blocking interface to the Internet Go Server protocol (used by 976 A non-blocking interface to the Internet Go Server protocol (used by
806 App::IGS). 977 App::IGS).
807 978
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 979 Net::FCP
816 AnyEvent-based implementation of the Freenet Client Protocol, 980 AnyEvent-based implementation of the Freenet Client Protocol,
817 birthplace of AnyEvent. 981 birthplace of AnyEvent.
818 982
819 Event::ExecFlow 983 Event::ExecFlow
820 High level API for event-based execution flow control. 984 High level API for event-based execution flow control.
821 985
822 Coro 986 Coro
823 Has special support for AnyEvent via Coro::AnyEvent. 987 Has special support for AnyEvent via Coro::AnyEvent.
824
825 IO::Lambda
826 The lambda approach to I/O - don't ask, look there. Can use
827 AnyEvent.
828 988
829ERROR AND EXCEPTION HANDLING 989ERROR AND EXCEPTION HANDLING
830 In general, AnyEvent does not do any error handling - it relies on the 990 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 991 caller to do that if required. The AnyEvent::Strict module (see also the
832 "PERL_ANYEVENT_STRICT" environment variable, below) provides strict 992 "PERL_ANYEVENT_STRICT" environment variable, below) provides strict
842 "condvar->recv"), the Event and EV modules call "$Event/EV::DIED->()", 1002 "condvar->recv"), the Event and EV modules call "$Event/EV::DIED->()",
843 Glib uses "install_exception_handler" and so on. 1003 Glib uses "install_exception_handler" and so on.
844 1004
845ENVIRONMENT VARIABLES 1005ENVIRONMENT VARIABLES
846 The following environment variables are used by this module or its 1006 The following environment variables are used by this module or its
847 submodules: 1007 submodules.
1008
1009 Note that AnyEvent will remove *all* environment variables starting with
1010 "PERL_ANYEVENT_" from %ENV when it is loaded while taint mode is
1011 enabled.
848 1012
849 "PERL_ANYEVENT_VERBOSE" 1013 "PERL_ANYEVENT_VERBOSE"
850 By default, AnyEvent will be completely silent except in fatal 1014 By default, AnyEvent will be completely silent except in fatal
851 conditions. You can set this environment variable to make AnyEvent 1015 conditions. You can set this environment variable to make AnyEvent
852 more talkative. 1016 more talkative.
855 conditions, such as not being able to load the event model specified 1019 conditions, such as not being able to load the event model specified
856 by "PERL_ANYEVENT_MODEL". 1020 by "PERL_ANYEVENT_MODEL".
857 1021
858 When set to 2 or higher, cause AnyEvent to report to STDERR which 1022 When set to 2 or higher, cause AnyEvent to report to STDERR which
859 event model it chooses. 1023 event model it chooses.
1024
1025 When set to 8 or higher, then AnyEvent will report extra information
1026 on which optional modules it loads and how it implements certain
1027 features.
860 1028
861 "PERL_ANYEVENT_STRICT" 1029 "PERL_ANYEVENT_STRICT"
862 AnyEvent does not do much argument checking by default, as thorough 1030 AnyEvent does not do much argument checking by default, as thorough
863 argument checking is very costly. Setting this variable to a true 1031 argument checking is very costly. Setting this variable to a true
864 value will cause AnyEvent to load "AnyEvent::Strict" and then to 1032 value will cause AnyEvent to load "AnyEvent::Strict" and then to
865 thoroughly check the arguments passed to most method calls. If it 1033 thoroughly check the arguments passed to most method calls. If it
866 finds any problems it will croak. 1034 finds any problems, it will croak.
867 1035
868 In other words, enables "strict" mode. 1036 In other words, enables "strict" mode.
869 1037
870 Unlike "use strict", it is definitely recommended ot keep it off in 1038 Unlike "use strict" (or it's modern cousin, "use common::sense", it
871 production. Keeping "PERL_ANYEVENT_STRICT=1" in your environment 1039 is definitely recommended to keep it off in production. Keeping
1040 "PERL_ANYEVENT_STRICT=1" in your environment while developing
872 while developing programs can be very useful, however. 1041 programs can be very useful, however.
873 1042
874 "PERL_ANYEVENT_MODEL" 1043 "PERL_ANYEVENT_MODEL"
875 This can be used to specify the event model to be used by AnyEvent, 1044 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 1045 before auto detection and -probing kicks in. It must be a string
877 consisting entirely of ASCII letters. The string "AnyEvent::Impl::" 1046 consisting entirely of ASCII letters. The string "AnyEvent::Impl::"
918 EDNS0 in its DNS requests. 1087 EDNS0 in its DNS requests.
919 1088
920 "PERL_ANYEVENT_MAX_FORKS" 1089 "PERL_ANYEVENT_MAX_FORKS"
921 The maximum number of child processes that 1090 The maximum number of child processes that
922 "AnyEvent::Util::fork_call" will create in parallel. 1091 "AnyEvent::Util::fork_call" will create in parallel.
1092
1093 "PERL_ANYEVENT_MAX_OUTSTANDING_DNS"
1094 The default value for the "max_outstanding" parameter for the
1095 default DNS resolver - this is the maximum number of parallel DNS
1096 requests that are sent to the DNS server.
1097
1098 "PERL_ANYEVENT_RESOLV_CONF"
1099 The file to use instead of /etc/resolv.conf (or OS-specific
1100 configuration) in the default resolver. When set to the empty
1101 string, no default config will be used.
1102
1103 "PERL_ANYEVENT_CA_FILE", "PERL_ANYEVENT_CA_PATH".
1104 When neither "ca_file" nor "ca_path" was specified during
1105 AnyEvent::TLS context creation, and either of these environment
1106 variables exist, they will be used to specify CA certificate
1107 locations instead of a system-dependent default.
1108
1109 "PERL_ANYEVENT_AVOID_GUARD" and "PERL_ANYEVENT_AVOID_ASYNC_INTERRUPT"
1110 When these are set to 1, then the respective modules are not loaded.
1111 Mostly good for testing AnyEvent itself.
923 1112
924SUPPLYING YOUR OWN EVENT MODEL INTERFACE 1113SUPPLYING YOUR OWN EVENT MODEL INTERFACE
925 This is an advanced topic that you do not normally need to use AnyEvent 1114 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 1115 in a module. This section is only of use to event loop authors who want
927 to provide AnyEvent compatibility. 1116 to provide AnyEvent compatibility.
1163 EV/Any 100000 224 2.88 0.34 0.27 EV + AnyEvent watchers 1352 EV/Any 100000 224 2.88 0.34 0.27 EV + AnyEvent watchers
1164 CoroEV/Any 100000 224 2.85 0.35 0.28 coroutines + Coro::Signal 1353 CoroEV/Any 100000 224 2.85 0.35 0.28 coroutines + Coro::Signal
1165 Perl/Any 100000 452 4.13 0.73 0.95 pure perl implementation 1354 Perl/Any 100000 452 4.13 0.73 0.95 pure perl implementation
1166 Event/Event 16000 517 32.20 31.80 0.81 Event native interface 1355 Event/Event 16000 517 32.20 31.80 0.81 Event native interface
1167 Event/Any 16000 590 35.85 31.55 1.06 Event + AnyEvent watchers 1356 Event/Any 16000 590 35.85 31.55 1.06 Event + AnyEvent watchers
1357 IOAsync/Any 16000 989 38.10 32.77 11.13 via IO::Async::Loop::IO_Poll
1358 IOAsync/Any 16000 990 37.59 29.50 10.61 via IO::Async::Loop::Epoll
1168 Glib/Any 16000 1357 102.33 12.31 51.00 quadratic behaviour 1359 Glib/Any 16000 1357 102.33 12.31 51.00 quadratic behaviour
1169 Tk/Any 2000 1860 27.20 66.31 14.00 SEGV with >> 2000 watchers 1360 Tk/Any 2000 1860 27.20 66.31 14.00 SEGV with >> 2000 watchers
1170 POE/Event 2000 6328 109.99 751.67 14.02 via POE::Loop::Event 1361 POE/Event 2000 6328 109.99 751.67 14.02 via POE::Loop::Event
1171 POE/Select 2000 6027 94.54 809.13 579.80 via POE::Loop::Select 1362 POE/Select 2000 6027 94.54 809.13 579.80 via POE::Loop::Select
1172 1363
1201 few of them active), of course, but this was not subject of this 1392 few of them active), of course, but this was not subject of this
1202 benchmark. 1393 benchmark.
1203 1394
1204 The "Event" module has a relatively high setup and callback invocation 1395 The "Event" module has a relatively high setup and callback invocation
1205 cost, but overall scores in on the third place. 1396 cost, but overall scores in on the third place.
1397
1398 "IO::Async" performs admirably well, about on par with "Event", even
1399 when using its pure perl backend.
1206 1400
1207 "Glib"'s memory usage is quite a bit higher, but it features a faster 1401 "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". 1402 callback invocation and overall ends up in the same class as "Event".
1209 However, Glib scales extremely badly, doubling the number of watchers 1403 However, Glib scales extremely badly, doubling the number of watchers
1210 increases the processing time by more than a factor of four, making it 1404 increases the processing time by more than a factor of four, making it
1281 single "request", that is, reading the token from the pipe and 1475 single "request", that is, reading the token from the pipe and
1282 forwarding it to another server. This includes deleting the old timeout 1476 forwarding it to another server. This includes deleting the old timeout
1283 and creating a new one that moves the timeout into the future. 1477 and creating a new one that moves the timeout into the future.
1284 1478
1285 Results 1479 Results
1286 name sockets create request 1480 name sockets create request
1287 EV 20000 69.01 11.16 1481 EV 20000 69.01 11.16
1288 Perl 20000 73.32 35.87 1482 Perl 20000 73.32 35.87
1483 IOAsync 20000 157.00 98.14 epoll
1484 IOAsync 20000 159.31 616.06 poll
1289 Event 20000 212.62 257.32 1485 Event 20000 212.62 257.32
1290 Glib 20000 651.16 1896.30 1486 Glib 20000 651.16 1896.30
1291 POE 20000 349.67 12317.24 uses POE::Loop::Event 1487 POE 20000 349.67 12317.24 uses POE::Loop::Event
1292 1488
1293 Discussion 1489 Discussion
1294 This benchmark *does* measure scalability and overall performance of the 1490 This benchmark *does* measure scalability and overall performance of the
1295 particular event loop. 1491 particular event loop.
1296 1492
1297 EV is again fastest. Since it is using epoll on my system, the setup 1493 EV is again fastest. Since it is using epoll on my system, the setup
1298 time is relatively high, though. 1494 time is relatively high, though.
1299 1495
1300 Perl surprisingly comes second. It is much faster than the C-based event 1496 Perl surprisingly comes second. It is much faster than the C-based event
1301 loops Event and Glib. 1497 loops Event and Glib.
1498
1499 IO::Async performs very well when using its epoll backend, and still
1500 quite good compared to Glib when using its pure perl backend.
1302 1501
1303 Event suffers from high setup time as well (look at its code and you 1502 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 1503 will understand why). Callback invocation also has a high overhead
1305 compared to the "$_->() for .."-style loop that the Perl event loop 1504 compared to the "$_->() for .."-style loop that the Perl event loop
1306 uses. Event uses select or poll in basically all documented 1505 uses. Event uses select or poll in basically all documented
1357 1556
1358 Summary 1557 Summary
1359 * C-based event loops perform very well with small number of watchers, 1558 * C-based event loops perform very well with small number of watchers,
1360 as the management overhead dominates. 1559 as the management overhead dominates.
1361 1560
1561 THE IO::Lambda BENCHMARK
1562 Recently I was told about the benchmark in the IO::Lambda manpage, which
1563 could be misinterpreted to make AnyEvent look bad. In fact, the
1564 benchmark simply compares IO::Lambda with POE, and IO::Lambda looks
1565 better (which shouldn't come as a surprise to anybody). As such, the
1566 benchmark is fine, and mostly shows that the AnyEvent backend from
1567 IO::Lambda isn't very optimal. But how would AnyEvent compare when used
1568 without the extra baggage? To explore this, I wrote the equivalent
1569 benchmark for AnyEvent.
1570
1571 The benchmark itself creates an echo-server, and then, for 500 times,
1572 connects to the echo server, sends a line, waits for the reply, and then
1573 creates the next connection. This is a rather bad benchmark, as it
1574 doesn't test the efficiency of the framework or much non-blocking I/O,
1575 but it is a benchmark nevertheless.
1576
1577 name runtime
1578 Lambda/select 0.330 sec
1579 + optimized 0.122 sec
1580 Lambda/AnyEvent 0.327 sec
1581 + optimized 0.138 sec
1582 Raw sockets/select 0.077 sec
1583 POE/select, components 0.662 sec
1584 POE/select, raw sockets 0.226 sec
1585 POE/select, optimized 0.404 sec
1586
1587 AnyEvent/select/nb 0.085 sec
1588 AnyEvent/EV/nb 0.068 sec
1589 +state machine 0.134 sec
1590
1591 The benchmark is also a bit unfair (my fault): the IO::Lambda/POE
1592 benchmarks actually make blocking connects and use 100% blocking I/O,
1593 defeating the purpose of an event-based solution. All of the newly
1594 written AnyEvent benchmarks use 100% non-blocking connects (using
1595 AnyEvent::Socket::tcp_connect and the asynchronous pure perl DNS
1596 resolver), so AnyEvent is at a disadvantage here, as non-blocking
1597 connects generally require a lot more bookkeeping and event handling
1598 than blocking connects (which involve a single syscall only).
1599
1600 The last AnyEvent benchmark additionally uses AnyEvent::Handle, which
1601 offers similar expressive power as POE and IO::Lambda, using
1602 conventional Perl syntax. This means that both the echo server and the
1603 client are 100% non-blocking, further placing it at a disadvantage.
1604
1605 As you can see, the AnyEvent + EV combination even beats the
1606 hand-optimised "raw sockets benchmark", while AnyEvent + its pure perl
1607 backend easily beats IO::Lambda and POE.
1608
1609 And even the 100% non-blocking version written using the high-level (and
1610 slow :) AnyEvent::Handle abstraction beats both POE and IO::Lambda by a
1611 large margin, even though it does all of DNS, tcp-connect and socket I/O
1612 in a non-blocking way.
1613
1614 The two AnyEvent benchmarks programs can be found as eg/ae0.pl and
1615 eg/ae2.pl in the AnyEvent distribution, the remaining benchmarks are
1616 part of the IO::lambda distribution and were used without any changes.
1617
1362SIGNALS 1618SIGNALS
1363 AnyEvent currently installs handlers for these signals: 1619 AnyEvent currently installs handlers for these signals:
1364 1620
1365 SIGCHLD 1621 SIGCHLD
1366 A handler for "SIGCHLD" is installed by AnyEvent's child watcher 1622 A handler for "SIGCHLD" is installed by AnyEvent's child watcher
1367 emulation for event loops that do not support them natively. Also, 1623 emulation for event loops that do not support them natively. Also,
1368 some event loops install a similar handler. 1624 some event loops install a similar handler.
1625
1626 Additionally, when AnyEvent is loaded and SIGCHLD is set to IGNORE,
1627 then AnyEvent will reset it to default, to avoid losing child exit
1628 statuses.
1369 1629
1370 SIGPIPE 1630 SIGPIPE
1371 A no-op handler is installed for "SIGPIPE" when $SIG{PIPE} is 1631 A no-op handler is installed for "SIGPIPE" when $SIG{PIPE} is
1372 "undef" when AnyEvent gets loaded. 1632 "undef" when AnyEvent gets loaded.
1373 1633
1381 it is that this way, the handler will be restored to defaults on 1641 it is that this way, the handler will be restored to defaults on
1382 exec. 1642 exec.
1383 1643
1384 Feel free to install your own handler, or reset it to defaults. 1644 Feel free to install your own handler, or reset it to defaults.
1385 1645
1646RECOMMENDED/OPTIONAL MODULES
1647 One of AnyEvent's main goals is to be 100% Pure-Perl(tm): only perl (and
1648 it's built-in modules) are required to use it.
1649
1650 That does not mean that AnyEvent won't take advantage of some additional
1651 modules if they are installed.
1652
1653 This section epxlains which additional modules will be used, and how
1654 they affect AnyEvent's operetion.
1655
1656 Async::Interrupt
1657 This slightly arcane module is used to implement fast signal
1658 handling: To my knowledge, there is no way to do completely
1659 race-free and quick signal handling in pure perl. To ensure that
1660 signals still get delivered, AnyEvent will start an interval timer
1661 to wake up perl (and catch the signals) with some delay (default is
1662 10 seconds, look for $AnyEvent::MAX_SIGNAL_LATENCY).
1663
1664 If this module is available, then it will be used to implement
1665 signal catching, which means that signals will not be delayed, and
1666 the event loop will not be interrupted regularly, which is more
1667 efficient (And good for battery life on laptops).
1668
1669 This affects not just the pure-perl event loop, but also other event
1670 loops that have no signal handling on their own (e.g. Glib, Tk, Qt).
1671
1672 Some event loops (POE, Event, Event::Lib) offer signal watchers
1673 natively, and either employ their own workarounds (POE) or use
1674 AnyEvent's workaround (using $AnyEvent::MAX_SIGNAL_LATENCY).
1675 Installing Async::Interrupt does nothing for those backends.
1676
1677 EV This module isn't really "optional", as it is simply one of the
1678 backend event loops that AnyEvent can use. However, it is simply the
1679 best event loop available in terms of features, speed and stability:
1680 It supports the AnyEvent API optimally, implements all the watcher
1681 types in XS, does automatic timer adjustments even when no monotonic
1682 clock is available, can take avdantage of advanced kernel interfaces
1683 such as "epoll" and "kqueue", and is the fastest backend *by far*.
1684 You can even embed Glib/Gtk2 in it (or vice versa, see EV::Glib and
1685 Glib::EV).
1686
1687 Guard
1688 The guard module, when used, will be used to implement
1689 "AnyEvent::Util::guard". This speeds up guards considerably (and
1690 uses a lot less memory), but otherwise doesn't affect guard
1691 operation much. It is purely used for performance.
1692
1693 JSON and JSON::XS
1694 This module is required when you want to read or write JSON data via
1695 AnyEvent::Handle. It is also written in pure-perl, but can take
1696 advantage of the ultra-high-speed JSON::XS module when it is
1697 installed.
1698
1699 In fact, AnyEvent::Handle will use JSON::XS by default if it is
1700 installed.
1701
1702 Net::SSLeay
1703 Implementing TLS/SSL in Perl is certainly interesting, but not very
1704 worthwhile: If this module is installed, then AnyEvent::Handle (with
1705 the help of AnyEvent::TLS), gains the ability to do TLS/SSL.
1706
1707 Time::HiRes
1708 This module is part of perl since release 5.008. It will be used
1709 when the chosen event library does not come with a timing source on
1710 it's own. The pure-perl event loop (AnyEvent::Impl::Perl) will
1711 additionally use it to try to use a monotonic clock for timing
1712 stability.
1713
1386FORK 1714FORK
1387 Most event libraries are not fork-safe. The ones who are usually are 1715 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. 1716 because they rely on inefficient but fork-safe "select" or "poll" calls.
1389 Only EV is fully fork-aware. 1717 Only EV is fully fork-aware.
1390 1718
1391 If you have to fork, you must either do so *before* creating your first 1719 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. 1720 watcher OR you must not use AnyEvent at all in the child OR you must do
1721 something completely out of the scope of AnyEvent.
1393 1722
1394SECURITY CONSIDERATIONS 1723SECURITY CONSIDERATIONS
1395 AnyEvent can be forced to load any event model via 1724 AnyEvent can be forced to load any event model via
1396 $ENV{PERL_ANYEVENT_MODEL}. While this cannot (to my knowledge) be used 1725 $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 1726 to execute arbitrary code or directly gain access, it can easily be used
1401 1730
1402 You can make AnyEvent completely ignore this variable by deleting it 1731 You can make AnyEvent completely ignore this variable by deleting it
1403 before the first watcher gets created, e.g. with a "BEGIN" block: 1732 before the first watcher gets created, e.g. with a "BEGIN" block:
1404 1733
1405 BEGIN { delete $ENV{PERL_ANYEVENT_MODEL} } 1734 BEGIN { delete $ENV{PERL_ANYEVENT_MODEL} }
1406 1735
1407 use AnyEvent; 1736 use AnyEvent;
1408 1737
1409 Similar considerations apply to $ENV{PERL_ANYEVENT_VERBOSE}, as that can 1738 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 1739 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), 1740 is probably even less useful to an attacker than PERL_ANYEVENT_MODEL),
1412 and $ENV{PERL_ANYEGENT_STRICT}. 1741 and $ENV{PERL_ANYEVENT_STRICT}.
1742
1743 Note that AnyEvent will remove *all* environment variables starting with
1744 "PERL_ANYEVENT_" from %ENV when it is loaded while taint mode is
1745 enabled.
1413 1746
1414BUGS 1747BUGS
1415 Perl 5.8 has numerous memleaks that sometimes hit this module and are 1748 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 1749 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 1750 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, 1757 Event modules: EV, EV::Glib, Glib::EV, Event, Glib::Event, Glib, Tk,
1425 Event::Lib, Qt, POE. 1758 Event::Lib, Qt, POE.
1426 1759
1427 Implementations: AnyEvent::Impl::EV, AnyEvent::Impl::Event, 1760 Implementations: AnyEvent::Impl::EV, AnyEvent::Impl::Event,
1428 AnyEvent::Impl::Glib, AnyEvent::Impl::Tk, AnyEvent::Impl::Perl, 1761 AnyEvent::Impl::Glib, AnyEvent::Impl::Tk, AnyEvent::Impl::Perl,
1429 AnyEvent::Impl::EventLib, AnyEvent::Impl::Qt, AnyEvent::Impl::POE. 1762 AnyEvent::Impl::EventLib, AnyEvent::Impl::Qt, AnyEvent::Impl::POE,
1763 AnyEvent::Impl::IOAsync.
1430 1764
1431 Non-blocking file handles, sockets, TCP clients and servers: 1765 Non-blocking file handles, sockets, TCP clients and servers:
1432 AnyEvent::Handle, AnyEvent::Socket. 1766 AnyEvent::Handle, AnyEvent::Socket, AnyEvent::TLS.
1433 1767
1434 Asynchronous DNS: AnyEvent::DNS. 1768 Asynchronous DNS: AnyEvent::DNS.
1435 1769
1436 Coroutine support: Coro, Coro::AnyEvent, Coro::EV, Coro::Event, 1770 Coroutine support: Coro, Coro::AnyEvent, Coro::EV, Coro::Event,
1437 1771
1438 Nontrivial usage examples: Net::FCP, Net::XMPP2, AnyEvent::DNS. 1772 Nontrivial usage examples: AnyEvent::GPSD, AnyEvent::XMPP,
1773 AnyEvent::HTTP.
1439 1774
1440AUTHOR 1775AUTHOR
1441 Marc Lehmann <schmorp@schmorp.de> 1776 Marc Lehmann <schmorp@schmorp.de>
1442 http://home.schmorp.de/ 1777 http://home.schmorp.de/
1443 1778

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines