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

Comparing AnyEvent/README (file contents):
Revision 1.40 by root, Tue Jun 23 23:37:32 2009 UTC vs.
Revision 1.46 by root, Sat Jul 18 05:19:09 2009 UTC

… …
169 169
170 I/O WATCHERS 170 I/O WATCHERS
171 You can create an I/O watcher by calling the "AnyEvent->io" method with 171 You can create an I/O watcher by calling the "AnyEvent->io" method with
172 the following mandatory key-value pairs as arguments: 172 the following mandatory key-value pairs as arguments:
173 173
174 "fh" is the Perl *file handle* (*not* file descriptor) to watch for 174 "fh" is the Perl *file handle* (or a naked file descriptor) to watch for
175 events (AnyEvent might or might not keep a reference to this file 175 events (AnyEvent might or might not keep a reference to this file
176 handle). Note that only file handles pointing to things for which 176 handle). Note that only file handles pointing to things for which
177 non-blocking operation makes sense are allowed. This includes sockets, 177 non-blocking operation makes sense are allowed. This includes sockets,
178 most character devices, pipes, fifos and so on, but not for example 178 most character devices, pipes, fifos and so on, but not for example
179 files or block devices. 179 files or block devices.
… …
350 invocation, and callback invocation will be synchronous. Synchronous 350 invocation, and callback invocation will be synchronous. Synchronous
351 means that it might take a while until the signal gets handled by the 351 means that it might take a while until the signal gets handled by the
352 process, but it is guaranteed not to interrupt any other callbacks. 352 process, but it is guaranteed not to interrupt any other callbacks.
353 353
354 The main advantage of using these watchers is that you can share a 354 The main advantage of using these watchers is that you can share a
355 signal between multiple watchers. 355 signal between multiple watchers, and AnyEvent will ensure that signals
356 will not interrupt your program at bad times.
356 357
357 This watcher might use %SIG, so programs overwriting those signals 358 This watcher might use %SIG (depending on the event loop used), so
358 directly will likely not work correctly. 359 programs overwriting those signals directly will likely not work
360 correctly.
361
362 Also note that many event loops (e.g. Glib, Tk, Qt, IO::Async) do not
363 support attaching callbacks to signals, which is a pity, as you cannot
364 do race-free signal handling in perl. AnyEvent will try to do it's best,
365 but in some cases, signals will be delayed. The maximum time a signal
366 might be delayed is specified in $AnyEvent::MAX_SIGNAL_LATENCY (default:
367 10 seconds). This variable can be changed only before the first signal
368 watcher is created, and should be left alone otherwise. Higher values
369 will cause fewer spurious wake-ups, which is better for power and CPU
370 saving. All these problems can be avoided by installing the optional
371 Async::Interrupt module.
359 372
360 Example: exit on SIGINT 373 Example: exit on SIGINT
361 374
362 my $w = AnyEvent->signal (signal => "INT", cb => sub { exit 1 }); 375 my $w = AnyEvent->signal (signal => "INT", cb => sub { exit 1 });
363 376
… …
380 393
381 There is a slight catch to child watchers, however: you usually start 394 There is a slight catch to child watchers, however: you usually start
382 them *after* the child process was created, and this means the process 395 them *after* the child process was created, and this means the process
383 could have exited already (and no SIGCHLD will be sent anymore). 396 could have exited already (and no SIGCHLD will be sent anymore).
384 397
385 Not all event models handle this correctly (POE doesn't), but even for 398 Not all event models handle this correctly (neither POE nor IO::Async
399 do, see their AnyEvent::Impl manpages for details), but even for event
386 event models that *do* handle this correctly, they usually need to be 400 models that *do* handle this correctly, they usually need to be loaded
387 loaded before the process exits (i.e. before you fork in the first 401 before the process exits (i.e. before you fork in the first place).
388 place). 402 AnyEvent's pure perl event loop handles all cases correctly regardless
403 of when you start the watcher.
389 404
390 This means you cannot create a child watcher as the very first thing in 405 This means you cannot create a child watcher as the very first thing in
391 an AnyEvent program, you *have* to create at least one watcher before 406 an AnyEvent program, you *have* to create at least one watcher before
392 you "fork" the child (alternatively, you can call "AnyEvent::detect"). 407 you "fork" the child (alternatively, you can call "AnyEvent::detect").
408
409 As most event loops do not support waiting for child events, they will
410 be emulated by AnyEvent in most cases, in which the latency and race
411 problems mentioned in the description of signal watchers apply.
393 412
394 Example: fork a process and wait for it 413 Example: fork a process and wait for it
395 414
396 my $done = AnyEvent->condvar; 415 my $done = AnyEvent->condvar;
397 416
… …
446 CONDITION VARIABLES 465 CONDITION VARIABLES
447 If you are familiar with some event loops you will know that all of them 466 If you are familiar with some event loops you will know that all of them
448 require you to run some blocking "loop", "run" or similar function that 467 require you to run some blocking "loop", "run" or similar function that
449 will actively watch for new events and call your callbacks. 468 will actively watch for new events and call your callbacks.
450 469
451 AnyEvent is different, it expects somebody else to run the event loop 470 AnyEvent is slightly different: it expects somebody else to run the
452 and will only block when necessary (usually when told by the user). 471 event loop and will only block when necessary (usually when told by the
472 user).
453 473
454 The instrument to do that is called a "condition variable", so called 474 The instrument to do that is called a "condition variable", so called
455 because they represent a condition that must become true. 475 because they represent a condition that must become true.
456 476
477 Now is probably a good time to look at the examples further below.
478
457 Condition variables can be created by calling the "AnyEvent->condvar" 479 Condition variables can be created by calling the "AnyEvent->condvar"
458 method, usually without arguments. The only argument pair allowed is 480 method, usually without arguments. The only argument pair allowed is
459
460 "cb", which specifies a callback to be called when the condition 481 "cb", which specifies a callback to be called when the condition
461 variable becomes true, with the condition variable as the first argument 482 variable becomes true, with the condition variable as the first argument
462 (but not the results). 483 (but not the results).
463 484
464 After creation, the condition variable is "false" until it becomes 485 After creation, the condition variable is "false" until it becomes
… …
513 after => 1, 534 after => 1,
514 cb => sub { $result_ready->send }, 535 cb => sub { $result_ready->send },
515 ); 536 );
516 537
517 # this "blocks" (while handling events) till the callback 538 # this "blocks" (while handling events) till the callback
518 # calls send 539 # calls -<send
519 $result_ready->recv; 540 $result_ready->recv;
520 541
521 Example: wait for a timer, but take advantage of the fact that condition 542 Example: wait for a timer, but take advantage of the fact that condition
522 variables are also code references. 543 variables are also callable directly.
523 544
524 my $done = AnyEvent->condvar; 545 my $done = AnyEvent->condvar;
525 my $delay = AnyEvent->timer (after => 5, cb => $done); 546 my $delay = AnyEvent->timer (after => 5, cb => $done);
526 $done->recv; 547 $done->recv;
527 548
… …
533 554
534 ... 555 ...
535 556
536 my @info = $couchdb->info->recv; 557 my @info = $couchdb->info->recv;
537 558
538 And this is how you would just ste a callback to be called whenever the 559 And this is how you would just set a callback to be called whenever the
539 results are available: 560 results are available:
540 561
541 $couchdb->info->cb (sub { 562 $couchdb->info->cb (sub {
542 my @info = $_[0]->recv; 563 my @info = $_[0]->recv;
543 }); 564 });
… …
558 579
559 Any arguments passed to the "send" call will be returned by all 580 Any arguments passed to the "send" call will be returned by all
560 future "->recv" calls. 581 future "->recv" calls.
561 582
562 Condition variables are overloaded so one can call them directly (as 583 Condition variables are overloaded so one can call them directly (as
563 a code reference). Calling them directly is the same as calling 584 if they were a code reference). Calling them directly is the same as
564 "send". Note, however, that many C-based event loops do not handle 585 calling "send".
565 overloading, so as tempting as it may be, passing a condition
566 variable instead of a callback does not work. Both the pure perl and
567 EV loops support overloading, however, as well as all functions that
568 use perl to invoke a callback (as in AnyEvent::Socket and
569 AnyEvent::DNS for example).
570 586
571 $cv->croak ($error) 587 $cv->croak ($error)
572 Similar to send, but causes all call's to "->recv" to invoke 588 Similar to send, but causes all call's to "->recv" to invoke
573 "Carp::croak" with the given error message/object/scalar. 589 "Carp::croak" with the given error message/object/scalar.
574 590
575 This can be used to signal any errors to the condition variable 591 This can be used to signal any errors to the condition variable
576 user/consumer. 592 user/consumer. Doing it this way instead of calling "croak" directly
593 delays the error detetcion, but has the overwhelmign advantage that
594 it diagnoses the error at the place where the result is expected,
595 and not deep in some event clalback without connection to the actual
596 code causing the problem.
577 597
578 $cv->begin ([group callback]) 598 $cv->begin ([group callback])
579 $cv->end 599 $cv->end
580 These two methods are EXPERIMENTAL and MIGHT CHANGE.
581
582 These two methods can be used to combine many transactions/events 600 These two methods can be used to combine many transactions/events
583 into one. For example, a function that pings many hosts in parallel 601 into one. For example, a function that pings many hosts in parallel
584 might want to use a condition variable for the whole process. 602 might want to use a condition variable for the whole process.
585 603
586 Every call to "->begin" will increment a counter, and every call to 604 Every call to "->begin" will increment a counter, and every call to
587 "->end" will decrement it. If the counter reaches 0 in "->end", the 605 "->end" will decrement it. If the counter reaches 0 in "->end", the
588 (last) callback passed to "begin" will be executed. That callback is 606 (last) callback passed to "begin" will be executed. That callback is
589 *supposed* to call "->send", but that is not required. If no 607 *supposed* to call "->send", but that is not required. If no
590 callback was set, "send" will be called without any arguments. 608 callback was set, "send" will be called without any arguments.
591 609
592 Let's clarify this with the ping example: 610 You can think of "$cv->send" giving you an OR condition (one call
611 sends), while "$cv->begin" and "$cv->end" giving you an AND
612 condition (all "begin" calls must be "end"'ed before the condvar
613 sends).
614
615 Let's start with a simple example: you have two I/O watchers (for
616 example, STDOUT and STDERR for a program), and you want to wait for
617 both streams to close before activating a condvar:
618
619 my $cv = AnyEvent->condvar;
620
621 $cv->begin; # first watcher
622 my $w1 = AnyEvent->io (fh => $fh1, cb => sub {
623 defined sysread $fh1, my $buf, 4096
624 or $cv->end;
625 });
626
627 $cv->begin; # second watcher
628 my $w2 = AnyEvent->io (fh => $fh2, cb => sub {
629 defined sysread $fh2, my $buf, 4096
630 or $cv->end;
631 });
632
633 $cv->recv;
634
635 This works because for every event source (EOF on file handle),
636 there is one call to "begin", so the condvar waits for all calls to
637 "end" before sending.
638
639 The ping example mentioned above is slightly more complicated, as
640 the there are results to be passwd back, and the number of tasks
641 that are begung can potentially be zero:
593 642
594 my $cv = AnyEvent->condvar; 643 my $cv = AnyEvent->condvar;
595 644
596 my %result; 645 my %result;
597 $cv->begin (sub { $cv->send (\%result) }); 646 $cv->begin (sub { $cv->send (\%result) });
… …
617 the loop, which serves two important purposes: first, it sets the 666 the loop, which serves two important purposes: first, it sets the
618 callback to be called once the counter reaches 0, and second, it 667 callback to be called once the counter reaches 0, and second, it
619 ensures that "send" is called even when "no" hosts are being pinged 668 ensures that "send" is called even when "no" hosts are being pinged
620 (the loop doesn't execute once). 669 (the loop doesn't execute once).
621 670
622 This is the general pattern when you "fan out" into multiple 671 This is the general pattern when you "fan out" into multiple (but
623 subrequests: use an outer "begin"/"end" pair to set the callback and 672 potentially none) subrequests: use an outer "begin"/"end" pair to
624 ensure "end" is called at least once, and then, for each subrequest 673 set the callback and ensure "end" is called at least once, and then,
625 you start, call "begin" and for each subrequest you finish, call 674 for each subrequest you start, call "begin" and for each subrequest
626 "end". 675 you finish, call "end".
627 676
628 METHODS FOR CONSUMERS 677 METHODS FOR CONSUMERS
629 These methods should only be used by the consuming side, i.e. the code 678 These methods should only be used by the consuming side, i.e. the code
630 awaits the condition. 679 awaits the condition.
631 680
… …
640 function will call "croak". 689 function will call "croak".
641 690
642 In list context, all parameters passed to "send" will be returned, 691 In list context, all parameters passed to "send" will be returned,
643 in scalar context only the first one will be returned. 692 in scalar context only the first one will be returned.
644 693
694 Note that doing a blocking wait in a callback is not supported by
695 any event loop, that is, recursive invocation of a blocking "->recv"
696 is not allowed, and the "recv" call will "croak" if such a condition
697 is detected. This condition can be slightly loosened by using
698 Coro::AnyEvent, which allows you to do a blocking "->recv" from any
699 thread that doesn't run the event loop itself.
700
645 Not all event models support a blocking wait - some die in that case 701 Not all event models support a blocking wait - some die in that case
646 (programs might want to do that to stay interactive), so *if you are 702 (programs might want to do that to stay interactive), so *if you are
647 using this from a module, never require a blocking wait*, but let 703 using this from a module, never require a blocking wait*. Instead,
648 the caller decide whether the call will block or not (for example, 704 let the caller decide whether the call will block or not (for
649 by coupling condition variables with some kind of request results 705 example, by coupling condition variables with some kind of request
650 and supporting callbacks so the caller knows that getting the result 706 results and supporting callbacks so the caller knows that getting
651 will not block, while still supporting blocking waits if the caller 707 the result will not block, while still supporting blocking waits if
652 so desires). 708 the caller so desires).
653
654 Another reason *never* to "->recv" in a module is that you cannot
655 sensibly have two "->recv"'s in parallel, as that would require
656 multiple interpreters or coroutines/threads, none of which
657 "AnyEvent" can supply.
658
659 The Coro module, however, *can* and *does* supply coroutines and, in
660 fact, Coro::AnyEvent replaces AnyEvent's condvars by coroutine-safe
661 versions and also integrates coroutines into AnyEvent, making
662 blocking "->recv" calls perfectly safe as long as they are done from
663 another coroutine (one that doesn't run the event loop).
664 709
665 You can ensure that "-recv" never blocks by setting a callback and 710 You can ensure that "-recv" never blocks by setting a callback and
666 only calling "->recv" from within that callback (or at a later 711 only calling "->recv" from within that callback (or at a later
667 time). This will work even when the event loop does not support 712 time). This will work even when the event loop does not support
668 blocking waits otherwise. 713 blocking waits otherwise.
… …
678 The callback will be called when the condition becomes "true", i.e. 723 The callback will be called when the condition becomes "true", i.e.
679 when "send" or "croak" are called, with the only argument being the 724 when "send" or "croak" are called, with the only argument being the
680 condition variable itself. Calling "recv" inside the callback or at 725 condition variable itself. Calling "recv" inside the callback or at
681 any later time is guaranteed not to block. 726 any later time is guaranteed not to block.
682 727
728SUPPORTED EVENT LOOPS/BACKENDS
729 The available backend classes are (every class has its own manpage):
730
731 Backends that are autoprobed when no other event loop can be found.
732 EV is the preferred backend when no other event loop seems to be in
733 use. If EV is not installed, then AnyEvent will try Event, and,
734 failing that, will fall back to its own pure-perl implementation,
735 which is available everywhere as it comes with AnyEvent itself.
736
737 AnyEvent::Impl::EV based on EV (interface to libev, best choice).
738 AnyEvent::Impl::Event based on Event, very stable, few glitches.
739 AnyEvent::Impl::Perl pure-perl implementation, fast and portable.
740
741 Backends that are transparently being picked up when they are used.
742 These will be used when they are currently loaded when the first
743 watcher is created, in which case it is assumed that the application
744 is using them. This means that AnyEvent will automatically pick the
745 right backend when the main program loads an event module before
746 anything starts to create watchers. Nothing special needs to be done
747 by the main program.
748
749 AnyEvent::Impl::Glib based on Glib, slow but very stable.
750 AnyEvent::Impl::Tk based on Tk, very broken.
751 AnyEvent::Impl::EventLib based on Event::Lib, leaks memory and worse.
752 AnyEvent::Impl::POE based on POE, very slow, some limitations.
753
754 Backends with special needs.
755 Qt requires the Qt::Application to be instantiated first, but will
756 otherwise be picked up automatically. As long as the main program
757 instantiates the application before any AnyEvent watchers are
758 created, everything should just work.
759
760 AnyEvent::Impl::Qt based on Qt.
761
762 Support for IO::Async can only be partial, as it is too broken and
763 architecturally limited to even support the AnyEvent API. It also is
764 the only event loop that needs the loop to be set explicitly, so it
765 can only be used by a main program knowing about AnyEvent. See
766 AnyEvent::Impl::Async for the gory details.
767
768 AnyEvent::Impl::IOAsync based on IO::Async, cannot be autoprobed.
769
770 Event loops that are indirectly supported via other backends.
771 Some event loops can be supported via other modules:
772
773 There is no direct support for WxWidgets (Wx) or Prima.
774
775 WxWidgets has no support for watching file handles. However, you can
776 use WxWidgets through the POE adaptor, as POE has a Wx backend that
777 simply polls 20 times per second, which was considered to be too
778 horrible to even consider for AnyEvent.
779
780 Prima is not supported as nobody seems to be using it, but it has a
781 POE backend, so it can be supported through POE.
782
783 AnyEvent knows about both Prima and Wx, however, and will try to
784 load POE when detecting them, in the hope that POE will pick them
785 up, in which case everything will be automatic.
786
683GLOBAL VARIABLES AND FUNCTIONS 787GLOBAL VARIABLES AND FUNCTIONS
788 These are not normally required to use AnyEvent, but can be useful to
789 write AnyEvent extension modules.
790
684 $AnyEvent::MODEL 791 $AnyEvent::MODEL
685 Contains "undef" until the first watcher is being created. Then it 792 Contains "undef" until the first watcher is being created, before
793 the backend has been autodetected.
794
686 contains the event model that is being used, which is the name of 795 Afterwards it contains the event model that is being used, which is
687 the Perl class implementing the model. This class is usually one of 796 the name of the Perl class implementing the model. This class is
688 the "AnyEvent::Impl:xxx" modules, but can be any other class in the 797 usually one of the "AnyEvent::Impl:xxx" modules, but can be any
689 case AnyEvent has been extended at runtime (e.g. in *rxvt-unicode*). 798 other class in the case AnyEvent has been extended at runtime (e.g.
690 799 in *rxvt-unicode* it will be "urxvt::anyevent").
691 The known classes so far are:
692
693 AnyEvent::Impl::EV based on EV (an interface to libev, best choice).
694 AnyEvent::Impl::Event based on Event, second best choice.
695 AnyEvent::Impl::Perl pure-perl implementation, fast and portable.
696 AnyEvent::Impl::Glib based on Glib, third-best choice.
697 AnyEvent::Impl::Tk based on Tk, very bad choice.
698 AnyEvent::Impl::Qt based on Qt, cannot be autoprobed (see its docs).
699 AnyEvent::Impl::EventLib based on Event::Lib, leaks memory and worse.
700 AnyEvent::Impl::POE based on POE, not generic enough for full support.
701
702 There is no support for WxWidgets, as WxWidgets has no support for
703 watching file handles. However, you can use WxWidgets through the
704 POE Adaptor, as POE has a Wx backend that simply polls 20 times per
705 second, which was considered to be too horrible to even consider for
706 AnyEvent. Likewise, other POE backends can be used by AnyEvent by
707 using it's adaptor.
708
709 AnyEvent knows about Prima and Wx and will try to use POE when
710 autodetecting them.
711 800
712 AnyEvent::detect 801 AnyEvent::detect
713 Returns $AnyEvent::MODEL, forcing autodetection of the event model 802 Returns $AnyEvent::MODEL, forcing autodetection of the event model
714 if necessary. You should only call this function right before you 803 if necessary. You should only call this function right before you
715 would have created an AnyEvent watcher anyway, that is, as late as 804 would have created an AnyEvent watcher anyway, that is, as late as
716 possible at runtime. 805 possible at runtime, and not e.g. while initialising of your module.
806
807 If you need to do some initialisation before AnyEvent watchers are
808 created, use "post_detect".
717 809
718 $guard = AnyEvent::post_detect { BLOCK } 810 $guard = AnyEvent::post_detect { BLOCK }
719 Arranges for the code block to be executed as soon as the event 811 Arranges for the code block to be executed as soon as the event
720 model is autodetected (or immediately if this has already happened). 812 model is autodetected (or immediately if this has already happened).
813
814 The block will be executed *after* the actual backend has been
815 detected ($AnyEvent::MODEL is set), but *before* any watchers have
816 been created, so it is possible to e.g. patch @AnyEvent::ISA or do
817 other initialisations - see the sources of AnyEvent::Strict or
818 AnyEvent::AIO to see how this is used.
819
820 The most common usage is to create some global watchers, without
821 forcing event module detection too early, for example, AnyEvent::AIO
822 creates and installs the global IO::AIO watcher in a "post_detect"
823 block to avoid autodetecting the event module at load time.
721 824
722 If called in scalar or list context, then it creates and returns an 825 If called in scalar or list context, then it creates and returns an
723 object that automatically removes the callback again when it is 826 object that automatically removes the callback again when it is
724 destroyed. See Coro::BDB for a case where this is useful. 827 destroyed. See Coro::BDB for a case where this is useful.
725 828
… …
727 If there are any code references in this array (you can "push" to it 830 If there are any code references in this array (you can "push" to it
728 before or after loading AnyEvent), then they will called directly 831 before or after loading AnyEvent), then they will called directly
729 after the event loop has been chosen. 832 after the event loop has been chosen.
730 833
731 You should check $AnyEvent::MODEL before adding to this array, 834 You should check $AnyEvent::MODEL before adding to this array,
732 though: if it contains a true value then the event loop has already 835 though: if it is defined then the event loop has already been
733 been detected, and the array will be ignored. 836 detected, and the array will be ignored.
734 837
735 Best use "AnyEvent::post_detect { BLOCK }" instead. 838 Best use "AnyEvent::post_detect { BLOCK }" when your application
839 allows it,as it takes care of these details.
840
841 This variable is mainly useful for modules that can do something
842 useful when AnyEvent is used and thus want to know when it is
843 initialised, but do not need to even load it by default. This array
844 provides the means to hook into AnyEvent passively, without loading
845 it.
736 846
737WHAT TO DO IN A MODULE 847WHAT TO DO IN A MODULE
738 As a module author, you should "use AnyEvent" and call AnyEvent methods 848 As a module author, you should "use AnyEvent" and call AnyEvent methods
739 freely, but you should not load a specific event module or rely on it. 849 freely, but you should not load a specific event module or rely on it.
740 850
… …
791 variable somewhere, waiting for it, and sending it when the program 901 variable somewhere, waiting for it, and sending it when the program
792 should exit cleanly. 902 should exit cleanly.
793 903
794OTHER MODULES 904OTHER MODULES
795 The following is a non-exhaustive list of additional modules that use 905 The following is a non-exhaustive list of additional modules that use
796 AnyEvent and can therefore be mixed easily with other AnyEvent modules 906 AnyEvent as a client and can therefore be mixed easily with other
797 in the same program. Some of the modules come with AnyEvent, some are 907 AnyEvent modules and other event loops in the same program. Some of the
798 available via CPAN. 908 modules come with AnyEvent, most are available via CPAN.
799 909
800 AnyEvent::Util 910 AnyEvent::Util
801 Contains various utility functions that replace often-used but 911 Contains various utility functions that replace often-used but
802 blocking functions such as "inet_aton" by event-/callback-based 912 blocking functions such as "inet_aton" by event-/callback-based
803 versions. 913 versions.
… …
809 more. 919 more.
810 920
811 AnyEvent::Handle 921 AnyEvent::Handle
812 Provide read and write buffers, manages watchers for reads and 922 Provide read and write buffers, manages watchers for reads and
813 writes, supports raw and formatted I/O, I/O queued and fully 923 writes, supports raw and formatted I/O, I/O queued and fully
814 transparent and non-blocking SSL/TLS. 924 transparent and non-blocking SSL/TLS (via AnyEvent::TLS.
815 925
816 AnyEvent::DNS 926 AnyEvent::DNS
817 Provides rich asynchronous DNS resolver capabilities. 927 Provides rich asynchronous DNS resolver capabilities.
818 928
819 AnyEvent::HTTP 929 AnyEvent::HTTP
… …
840 950
841 AnyEvent::GPSD 951 AnyEvent::GPSD
842 A non-blocking interface to gpsd, a daemon delivering GPS 952 A non-blocking interface to gpsd, a daemon delivering GPS
843 information. 953 information.
844 954
955 AnyEvent::IRC
956 AnyEvent based IRC client module family (replacing the older
957 Net::IRC3).
958
959 AnyEvent::XMPP
960 AnyEvent based XMPP (Jabber protocol) module family (replacing the
961 older Net::XMPP2>.
962
845 AnyEvent::IGS 963 AnyEvent::IGS
846 A non-blocking interface to the Internet Go Server protocol (used by 964 A non-blocking interface to the Internet Go Server protocol (used by
847 App::IGS). 965 App::IGS).
848 966
849 AnyEvent::IRC
850 AnyEvent based IRC client module family (replacing the older
851 Net::IRC3).
852
853 Net::XMPP2
854 AnyEvent based XMPP (Jabber protocol) module family.
855
856 Net::FCP 967 Net::FCP
857 AnyEvent-based implementation of the Freenet Client Protocol, 968 AnyEvent-based implementation of the Freenet Client Protocol,
858 birthplace of AnyEvent. 969 birthplace of AnyEvent.
859 970
860 Event::ExecFlow 971 Event::ExecFlow
861 High level API for event-based execution flow control. 972 High level API for event-based execution flow control.
862 973
863 Coro 974 Coro
864 Has special support for AnyEvent via Coro::AnyEvent. 975 Has special support for AnyEvent via Coro::AnyEvent.
865
866 IO::Lambda
867 The lambda approach to I/O - don't ask, look there. Can use
868 AnyEvent.
869 976
870ERROR AND EXCEPTION HANDLING 977ERROR AND EXCEPTION HANDLING
871 In general, AnyEvent does not do any error handling - it relies on the 978 In general, AnyEvent does not do any error handling - it relies on the
872 caller to do that if required. The AnyEvent::Strict module (see also the 979 caller to do that if required. The AnyEvent::Strict module (see also the
873 "PERL_ANYEVENT_STRICT" environment variable, below) provides strict 980 "PERL_ANYEVENT_STRICT" environment variable, below) provides strict
… …
901 by "PERL_ANYEVENT_MODEL". 1008 by "PERL_ANYEVENT_MODEL".
902 1009
903 When set to 2 or higher, cause AnyEvent to report to STDERR which 1010 When set to 2 or higher, cause AnyEvent to report to STDERR which
904 event model it chooses. 1011 event model it chooses.
905 1012
1013 When set to 8 or higher, then AnyEvent will report extra information
1014 on which optional modules it loads and how it implements certain
1015 features.
1016
906 "PERL_ANYEVENT_STRICT" 1017 "PERL_ANYEVENT_STRICT"
907 AnyEvent does not do much argument checking by default, as thorough 1018 AnyEvent does not do much argument checking by default, as thorough
908 argument checking is very costly. Setting this variable to a true 1019 argument checking is very costly. Setting this variable to a true
909 value will cause AnyEvent to load "AnyEvent::Strict" and then to 1020 value will cause AnyEvent to load "AnyEvent::Strict" and then to
910 thoroughly check the arguments passed to most method calls. If it 1021 thoroughly check the arguments passed to most method calls. If it
911 finds any problems it will croak. 1022 finds any problems, it will croak.
912 1023
913 In other words, enables "strict" mode. 1024 In other words, enables "strict" mode.
914 1025
915 Unlike "use strict", it is definitely recommended ot keep it off in 1026 Unlike "use strict" (or it's modern cousin, "use common::sense", it
916 production. Keeping "PERL_ANYEVENT_STRICT=1" in your environment 1027 is definitely recommended to keep it off in production. Keeping
1028 "PERL_ANYEVENT_STRICT=1" in your environment while developing
917 while developing programs can be very useful, however. 1029 programs can be very useful, however.
918 1030
919 "PERL_ANYEVENT_MODEL" 1031 "PERL_ANYEVENT_MODEL"
920 This can be used to specify the event model to be used by AnyEvent, 1032 This can be used to specify the event model to be used by AnyEvent,
921 before auto detection and -probing kicks in. It must be a string 1033 before auto detection and -probing kicks in. It must be a string
922 consisting entirely of ASCII letters. The string "AnyEvent::Impl::" 1034 consisting entirely of ASCII letters. The string "AnyEvent::Impl::"
… …
963 EDNS0 in its DNS requests. 1075 EDNS0 in its DNS requests.
964 1076
965 "PERL_ANYEVENT_MAX_FORKS" 1077 "PERL_ANYEVENT_MAX_FORKS"
966 The maximum number of child processes that 1078 The maximum number of child processes that
967 "AnyEvent::Util::fork_call" will create in parallel. 1079 "AnyEvent::Util::fork_call" will create in parallel.
1080
1081 "PERL_ANYEVENT_MAX_OUTSTANDING_DNS"
1082 The default value for the "max_outstanding" parameter for the
1083 default DNS resolver - this is the maximum number of parallel DNS
1084 requests that are sent to the DNS server.
1085
1086 "PERL_ANYEVENT_RESOLV_CONF"
1087 The file to use instead of /etc/resolv.conf (or OS-specific
1088 configuration) in the default resolver. When set to the empty
1089 string, no default config will be used.
1090
1091 "PERL_ANYEVENT_CA_FILE", "PERL_ANYEVENT_CA_PATH".
1092 When neither "ca_file" nor "ca_path" was specified during
1093 AnyEvent::TLS context creation, and either of these environment
1094 variables exist, they will be used to specify CA certificate
1095 locations instead of a system-dependent default.
1096
1097 "PERL_ANYEVENT_AVOID_GUARD" and "PERL_ANYEVENT_AVOID_ASYNC_INTERRUPT"
1098 When these are set to 1, then the respective modules are not loaded.
1099 Mostly good for testing AnyEvent itself.
968 1100
969SUPPLYING YOUR OWN EVENT MODEL INTERFACE 1101SUPPLYING YOUR OWN EVENT MODEL INTERFACE
970 This is an advanced topic that you do not normally need to use AnyEvent 1102 This is an advanced topic that you do not normally need to use AnyEvent
971 in a module. This section is only of use to event loop authors who want 1103 in a module. This section is only of use to event loop authors who want
972 to provide AnyEvent compatibility. 1104 to provide AnyEvent compatibility.
… …
1208 EV/Any 100000 224 2.88 0.34 0.27 EV + AnyEvent watchers 1340 EV/Any 100000 224 2.88 0.34 0.27 EV + AnyEvent watchers
1209 CoroEV/Any 100000 224 2.85 0.35 0.28 coroutines + Coro::Signal 1341 CoroEV/Any 100000 224 2.85 0.35 0.28 coroutines + Coro::Signal
1210 Perl/Any 100000 452 4.13 0.73 0.95 pure perl implementation 1342 Perl/Any 100000 452 4.13 0.73 0.95 pure perl implementation
1211 Event/Event 16000 517 32.20 31.80 0.81 Event native interface 1343 Event/Event 16000 517 32.20 31.80 0.81 Event native interface
1212 Event/Any 16000 590 35.85 31.55 1.06 Event + AnyEvent watchers 1344 Event/Any 16000 590 35.85 31.55 1.06 Event + AnyEvent watchers
1345 IOAsync/Any 16000 989 38.10 32.77 11.13 via IO::Async::Loop::IO_Poll
1346 IOAsync/Any 16000 990 37.59 29.50 10.61 via IO::Async::Loop::Epoll
1213 Glib/Any 16000 1357 102.33 12.31 51.00 quadratic behaviour 1347 Glib/Any 16000 1357 102.33 12.31 51.00 quadratic behaviour
1214 Tk/Any 2000 1860 27.20 66.31 14.00 SEGV with >> 2000 watchers 1348 Tk/Any 2000 1860 27.20 66.31 14.00 SEGV with >> 2000 watchers
1215 POE/Event 2000 6328 109.99 751.67 14.02 via POE::Loop::Event 1349 POE/Event 2000 6328 109.99 751.67 14.02 via POE::Loop::Event
1216 POE/Select 2000 6027 94.54 809.13 579.80 via POE::Loop::Select 1350 POE/Select 2000 6027 94.54 809.13 579.80 via POE::Loop::Select
1217 1351
… …
1246 few of them active), of course, but this was not subject of this 1380 few of them active), of course, but this was not subject of this
1247 benchmark. 1381 benchmark.
1248 1382
1249 The "Event" module has a relatively high setup and callback invocation 1383 The "Event" module has a relatively high setup and callback invocation
1250 cost, but overall scores in on the third place. 1384 cost, but overall scores in on the third place.
1385
1386 "IO::Async" performs admirably well, about on par with "Event", even
1387 when using its pure perl backend.
1251 1388
1252 "Glib"'s memory usage is quite a bit higher, but it features a faster 1389 "Glib"'s memory usage is quite a bit higher, but it features a faster
1253 callback invocation and overall ends up in the same class as "Event". 1390 callback invocation and overall ends up in the same class as "Event".
1254 However, Glib scales extremely badly, doubling the number of watchers 1391 However, Glib scales extremely badly, doubling the number of watchers
1255 increases the processing time by more than a factor of four, making it 1392 increases the processing time by more than a factor of four, making it
… …
1326 single "request", that is, reading the token from the pipe and 1463 single "request", that is, reading the token from the pipe and
1327 forwarding it to another server. This includes deleting the old timeout 1464 forwarding it to another server. This includes deleting the old timeout
1328 and creating a new one that moves the timeout into the future. 1465 and creating a new one that moves the timeout into the future.
1329 1466
1330 Results 1467 Results
1331 name sockets create request 1468 name sockets create request
1332 EV 20000 69.01 11.16 1469 EV 20000 69.01 11.16
1333 Perl 20000 73.32 35.87 1470 Perl 20000 73.32 35.87
1471 IOAsync 20000 157.00 98.14 epoll
1472 IOAsync 20000 159.31 616.06 poll
1334 Event 20000 212.62 257.32 1473 Event 20000 212.62 257.32
1335 Glib 20000 651.16 1896.30 1474 Glib 20000 651.16 1896.30
1336 POE 20000 349.67 12317.24 uses POE::Loop::Event 1475 POE 20000 349.67 12317.24 uses POE::Loop::Event
1337 1476
1338 Discussion 1477 Discussion
1339 This benchmark *does* measure scalability and overall performance of the 1478 This benchmark *does* measure scalability and overall performance of the
1340 particular event loop. 1479 particular event loop.
1341 1480
1342 EV is again fastest. Since it is using epoll on my system, the setup 1481 EV is again fastest. Since it is using epoll on my system, the setup
1343 time is relatively high, though. 1482 time is relatively high, though.
1344 1483
1345 Perl surprisingly comes second. It is much faster than the C-based event 1484 Perl surprisingly comes second. It is much faster than the C-based event
1346 loops Event and Glib. 1485 loops Event and Glib.
1486
1487 IO::Async performs very well when using its epoll backend, and still
1488 quite good compared to Glib when using its pure perl backend.
1347 1489
1348 Event suffers from high setup time as well (look at its code and you 1490 Event suffers from high setup time as well (look at its code and you
1349 will understand why). Callback invocation also has a high overhead 1491 will understand why). Callback invocation also has a high overhead
1350 compared to the "$_->() for .."-style loop that the Perl event loop 1492 compared to the "$_->() for .."-style loop that the Perl event loop
1351 uses. Event uses select or poll in basically all documented 1493 uses. Event uses select or poll in basically all documented
… …
1407 THE IO::Lambda BENCHMARK 1549 THE IO::Lambda BENCHMARK
1408 Recently I was told about the benchmark in the IO::Lambda manpage, which 1550 Recently I was told about the benchmark in the IO::Lambda manpage, which
1409 could be misinterpreted to make AnyEvent look bad. In fact, the 1551 could be misinterpreted to make AnyEvent look bad. In fact, the
1410 benchmark simply compares IO::Lambda with POE, and IO::Lambda looks 1552 benchmark simply compares IO::Lambda with POE, and IO::Lambda looks
1411 better (which shouldn't come as a surprise to anybody). As such, the 1553 better (which shouldn't come as a surprise to anybody). As such, the
1412 benchmark is fine, and shows that the AnyEvent backend from IO::Lambda 1554 benchmark is fine, and mostly shows that the AnyEvent backend from
1413 isn't very optimal. But how would AnyEvent compare when used without the 1555 IO::Lambda isn't very optimal. But how would AnyEvent compare when used
1414 extra baggage? To explore this, I wrote the equivalent benchmark for 1556 without the extra baggage? To explore this, I wrote the equivalent
1415 AnyEvent. 1557 benchmark for AnyEvent.
1416 1558
1417 The benchmark itself creates an echo-server, and then, for 500 times, 1559 The benchmark itself creates an echo-server, and then, for 500 times,
1418 connects to the echo server, sends a line, waits for the reply, and then 1560 connects to the echo server, sends a line, waits for the reply, and then
1419 creates the next connection. This is a rather bad benchmark, as it 1561 creates the next connection. This is a rather bad benchmark, as it
1420 doesn't test the efficiency of the framework, but it is a benchmark 1562 doesn't test the efficiency of the framework or much non-blocking I/O,
1421 nevertheless. 1563 but it is a benchmark nevertheless.
1422 1564
1423 name runtime 1565 name runtime
1424 Lambda/select 0.330 sec 1566 Lambda/select 0.330 sec
1425 + optimized 0.122 sec 1567 + optimized 0.122 sec
1426 Lambda/AnyEvent 0.327 sec 1568 Lambda/AnyEvent 0.327 sec
… …
1432 1574
1433 AnyEvent/select/nb 0.085 sec 1575 AnyEvent/select/nb 0.085 sec
1434 AnyEvent/EV/nb 0.068 sec 1576 AnyEvent/EV/nb 0.068 sec
1435 +state machine 0.134 sec 1577 +state machine 0.134 sec
1436 1578
1437 The benchmark is also a bit unfair (my fault) - the IO::Lambda 1579 The benchmark is also a bit unfair (my fault): the IO::Lambda/POE
1438 benchmarks actually make blocking connects and use 100% blocking I/O, 1580 benchmarks actually make blocking connects and use 100% blocking I/O,
1439 defeating the purpose of an event-based solution. All of the newly 1581 defeating the purpose of an event-based solution. All of the newly
1440 written AnyEvent benchmarks use 100% non-blocking connects (using 1582 written AnyEvent benchmarks use 100% non-blocking connects (using
1441 AnyEvent::Socket::tcp_connect and the asynchronous pure perl DNS 1583 AnyEvent::Socket::tcp_connect and the asynchronous pure perl DNS
1442 resolver), so AnyEvent is at a disadvantage here as non-blocking 1584 resolver), so AnyEvent is at a disadvantage here, as non-blocking
1443 connects generally require a lot more bookkeeping and event handling 1585 connects generally require a lot more bookkeeping and event handling
1444 than blocking connects (which involve a single syscall only). 1586 than blocking connects (which involve a single syscall only).
1445 1587
1446 The last AnyEvent benchmark additionally uses AnyEvent::Handle, which 1588 The last AnyEvent benchmark additionally uses AnyEvent::Handle, which
1447 offers similar expressive power as POE and IO::Lambda (using 1589 offers similar expressive power as POE and IO::Lambda, using
1448 conventional Perl syntax), which means both the echo server and the 1590 conventional Perl syntax. This means that both the echo server and the
1449 client are 100% non-blocking w.r.t. I/O, further placing it at a 1591 client are 100% non-blocking, further placing it at a disadvantage.
1450 disadvantage.
1451 1592
1452 As you can see, AnyEvent + EV even beats the hand-optimised "raw sockets 1593 As you can see, the AnyEvent + EV combination even beats the
1453 benchmark", while AnyEvent + its pure perl backend easily beats 1594 hand-optimised "raw sockets benchmark", while AnyEvent + its pure perl
1454 IO::Lambda and POE. 1595 backend easily beats IO::Lambda and POE.
1455 1596
1456 And even the 100% non-blocking version written using the high-level (and 1597 And even the 100% non-blocking version written using the high-level (and
1457 slow :) AnyEvent::Handle abstraction beats both POE and IO::Lambda, even 1598 slow :) AnyEvent::Handle abstraction beats both POE and IO::Lambda by a
1458 thought it does all of DNS, tcp-connect and socket I/O in a non-blocking 1599 large margin, even though it does all of DNS, tcp-connect and socket I/O
1459 way. 1600 in a non-blocking way.
1460 1601
1461 The two AnyEvent benchmarks can be found as eg/ae0.pl and eg/ae2.pl in 1602 The two AnyEvent benchmarks programs can be found as eg/ae0.pl and
1462 the AnyEvent distribution, the remaining benchmarks are part of the 1603 eg/ae2.pl in the AnyEvent distribution, the remaining benchmarks are
1463 IO::lambda distribution and were used without any changes. 1604 part of the IO::lambda distribution and were used without any changes.
1464 1605
1465SIGNALS 1606SIGNALS
1466 AnyEvent currently installs handlers for these signals: 1607 AnyEvent currently installs handlers for these signals:
1467 1608
1468 SIGCHLD 1609 SIGCHLD
1469 A handler for "SIGCHLD" is installed by AnyEvent's child watcher 1610 A handler for "SIGCHLD" is installed by AnyEvent's child watcher
1470 emulation for event loops that do not support them natively. Also, 1611 emulation for event loops that do not support them natively. Also,
1471 some event loops install a similar handler. 1612 some event loops install a similar handler.
1613
1614 Additionally, when AnyEvent is loaded and SIGCHLD is set to IGNORE,
1615 then AnyEvent will reset it to default, to avoid losing child exit
1616 statuses.
1472 1617
1473 SIGPIPE 1618 SIGPIPE
1474 A no-op handler is installed for "SIGPIPE" when $SIG{PIPE} is 1619 A no-op handler is installed for "SIGPIPE" when $SIG{PIPE} is
1475 "undef" when AnyEvent gets loaded. 1620 "undef" when AnyEvent gets loaded.
1476 1621
… …
1484 it is that this way, the handler will be restored to defaults on 1629 it is that this way, the handler will be restored to defaults on
1485 exec. 1630 exec.
1486 1631
1487 Feel free to install your own handler, or reset it to defaults. 1632 Feel free to install your own handler, or reset it to defaults.
1488 1633
1634RECOMMENDED/OPTIONAL MODULES
1635 One of AnyEvent's main goals is to be 100% Pure-Perl(tm): only perl (and
1636 it's built-in modules) are required to use it.
1637
1638 That does not mean that AnyEvent won't take advantage of some additional
1639 modules if they are installed.
1640
1641 This section epxlains which additional modules will be used, and how
1642 they affect AnyEvent's operetion.
1643
1644 Async::Interrupt
1645 This slightly arcane module is used to implement fast signal
1646 handling: To my knowledge, there is no way to do completely
1647 race-free and quick signal handling in pure perl. To ensure that
1648 signals still get delivered, AnyEvent will start an interval timer
1649 to wake up perl (and catch the signals) with soemd elay (default is
1650 10 seconds, look for $AnyEvent::MAX_SIGNAL_LATENCY).
1651
1652 If this module is available, then it will be used to implement
1653 signal catching, which means that signals will not be delayed, and
1654 the event loop will not be interrupted regularly, which is more
1655 efficient (And good for battery life on laptops).
1656
1657 This affects not just the pure-perl event loop, but also other event
1658 loops that have no signal handling on their own (e.g. Glib, Tk, Qt).
1659
1660 EV This module isn't really "optional", as it is simply one of the
1661 backend event loops that AnyEvent can use. However, it is simply the
1662 best event loop available in terms of features, speed and stability:
1663 It supports the AnyEvent API optimally, implements all the watcher
1664 types in XS, does automatic timer adjustments even when no monotonic
1665 clock is available, can take avdantage of advanced kernel interfaces
1666 such as "epoll" and "kqueue", and is the fastest backend *by far*.
1667 You can even embed Glib/Gtk2 in it (or vice versa, see EV::Glib and
1668 Glib::EV).
1669
1670 Guard
1671 The guard module, when used, will be used to implement
1672 "AnyEvent::Util::guard". This speeds up guards considerably (and
1673 uses a lot less memory), but otherwise doesn't affect guard
1674 operation much. It is purely used for performance.
1675
1676 JSON and JSON::XS
1677 This module is required when you want to read or write JSON data via
1678 AnyEvent::Handle. It is also written in pure-perl, but can take
1679 advantage of the ulta-high-speed JSON::XS module when it is
1680 installed.
1681
1682 In fact, AnyEvent::Handle will use JSON::XS by default if it is
1683 installed.
1684
1685 Net::SSLeay
1686 Implementing TLS/SSL in Perl is certainly interesting, but not very
1687 worthwhile: If this module is installed, then AnyEvent::Handle (with
1688 the help of AnyEvent::TLS), gains the ability to do TLS/SSL.
1689
1690 Time::HiRes
1691 This module is part of perl since release 5.008. It will be used
1692 when the chosen event library does not come with a timing source on
1693 it's own. The pure-perl event loop (AnyEvent::Impl::Perl) will
1694 additionally use it to try to use a monotonic clock for timing
1695 stability.
1696
1489FORK 1697FORK
1490 Most event libraries are not fork-safe. The ones who are usually are 1698 Most event libraries are not fork-safe. The ones who are usually are
1491 because they rely on inefficient but fork-safe "select" or "poll" calls. 1699 because they rely on inefficient but fork-safe "select" or "poll" calls.
1492 Only EV is fully fork-aware. 1700 Only EV is fully fork-aware.
1493 1701
1494 If you have to fork, you must either do so *before* creating your first 1702 If you have to fork, you must either do so *before* creating your first
1495 watcher OR you must not use AnyEvent at all in the child. 1703 watcher OR you must not use AnyEvent at all in the child OR you must do
1704 something completely out of the scope of AnyEvent.
1496 1705
1497SECURITY CONSIDERATIONS 1706SECURITY CONSIDERATIONS
1498 AnyEvent can be forced to load any event model via 1707 AnyEvent can be forced to load any event model via
1499 $ENV{PERL_ANYEVENT_MODEL}. While this cannot (to my knowledge) be used 1708 $ENV{PERL_ANYEVENT_MODEL}. While this cannot (to my knowledge) be used
1500 to execute arbitrary code or directly gain access, it can easily be used 1709 to execute arbitrary code or directly gain access, it can easily be used
… …
1512 Similar considerations apply to $ENV{PERL_ANYEVENT_VERBOSE}, as that can 1721 Similar considerations apply to $ENV{PERL_ANYEVENT_VERBOSE}, as that can
1513 be used to probe what backend is used and gain other information (which 1722 be used to probe what backend is used and gain other information (which
1514 is probably even less useful to an attacker than PERL_ANYEVENT_MODEL), 1723 is probably even less useful to an attacker than PERL_ANYEVENT_MODEL),
1515 and $ENV{PERL_ANYEVENT_STRICT}. 1724 and $ENV{PERL_ANYEVENT_STRICT}.
1516 1725
1726 Note that AnyEvent will remove *all* environment variables starting with
1727 "PERL_ANYEVENT_" from %ENV when it is loaded while taint mode is
1728 enabled.
1729
1517BUGS 1730BUGS
1518 Perl 5.8 has numerous memleaks that sometimes hit this module and are 1731 Perl 5.8 has numerous memleaks that sometimes hit this module and are
1519 hard to work around. If you suffer from memleaks, first upgrade to Perl 1732 hard to work around. If you suffer from memleaks, first upgrade to Perl
1520 5.10 and check wether the leaks still show up. (Perl 5.10.0 has other 1733 5.10 and check wether the leaks still show up. (Perl 5.10.0 has other
1521 annoying memleaks, such as leaking on "map" and "grep" but it is usually 1734 annoying memleaks, such as leaking on "map" and "grep" but it is usually
… …
1527 Event modules: EV, EV::Glib, Glib::EV, Event, Glib::Event, Glib, Tk, 1740 Event modules: EV, EV::Glib, Glib::EV, Event, Glib::Event, Glib, Tk,
1528 Event::Lib, Qt, POE. 1741 Event::Lib, Qt, POE.
1529 1742
1530 Implementations: AnyEvent::Impl::EV, AnyEvent::Impl::Event, 1743 Implementations: AnyEvent::Impl::EV, AnyEvent::Impl::Event,
1531 AnyEvent::Impl::Glib, AnyEvent::Impl::Tk, AnyEvent::Impl::Perl, 1744 AnyEvent::Impl::Glib, AnyEvent::Impl::Tk, AnyEvent::Impl::Perl,
1532 AnyEvent::Impl::EventLib, AnyEvent::Impl::Qt, AnyEvent::Impl::POE. 1745 AnyEvent::Impl::EventLib, AnyEvent::Impl::Qt, AnyEvent::Impl::POE,
1746 AnyEvent::Impl::IOAsync.
1533 1747
1534 Non-blocking file handles, sockets, TCP clients and servers: 1748 Non-blocking file handles, sockets, TCP clients and servers:
1535 AnyEvent::Handle, AnyEvent::Socket. 1749 AnyEvent::Handle, AnyEvent::Socket, AnyEvent::TLS.
1536 1750
1537 Asynchronous DNS: AnyEvent::DNS. 1751 Asynchronous DNS: AnyEvent::DNS.
1538 1752
1539 Coroutine support: Coro, Coro::AnyEvent, Coro::EV, Coro::Event, 1753 Coroutine support: Coro, Coro::AnyEvent, Coro::EV, Coro::Event,
1540 1754
1541 Nontrivial usage examples: Net::FCP, Net::XMPP2, AnyEvent::DNS. 1755 Nontrivial usage examples: AnyEvent::GPSD, AnyEvent::XMPP,
1756 AnyEvent::HTTP.
1542 1757
1543AUTHOR 1758AUTHOR
1544 Marc Lehmann <schmorp@schmorp.de> 1759 Marc Lehmann <schmorp@schmorp.de>
1545 http://home.schmorp.de/ 1760 http://home.schmorp.de/
1546 1761

Diff Legend

– Removed lines
+ Added lines
< Changed lines
> Changed lines