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

Comparing AnyEvent/README (file contents):
Revision 1.46 by root, Sat Jul 18 05:19:09 2009 UTC vs.
Revision 1.62 by root, Sun Jun 6 10:13:57 2010 UTC

1NAME 1NAME
2 AnyEvent - provide framework for multiple event loops 2 AnyEvent - the DBI of event loop programming
3 3
4 EV, Event, Glib, Tk, Perl, Event::Lib, Qt and POE are various supported 4 EV, Event, Glib, Tk, Perl, Event::Lib, Irssi, rxvt-unicode, IO::Async,
5 event loops. 5 Qt and POE are various supported event loops/environments.
6 6
7SYNOPSIS 7SYNOPSIS
8 use AnyEvent; 8 use AnyEvent;
9 9
10 # if you prefer function calls, look at the AE manpage for
11 # an alternative API.
12
10 # file descriptor readable 13 # file handle or descriptor readable
11 my $w = AnyEvent->io (fh => $fh, poll => "r", cb => sub { ... }); 14 my $w = AnyEvent->io (fh => $fh, poll => "r", cb => sub { ... });
12 15
13 # one-shot or repeating timers 16 # one-shot or repeating timers
14 my $w = AnyEvent->timer (after => $seconds, cb => sub { ... }); 17 my $w = AnyEvent->timer (after => $seconds, cb => sub { ... });
15 my $w = AnyEvent->timer (after => $seconds, interval => $seconds, cb => ... 18 my $w = AnyEvent->timer (after => $seconds, interval => $seconds, cb => ...
… …
37 40
38INTRODUCTION/TUTORIAL 41INTRODUCTION/TUTORIAL
39 This manpage is mainly a reference manual. If you are interested in a 42 This manpage is mainly a reference manual. If you are interested in a
40 tutorial or some gentle introduction, have a look at the AnyEvent::Intro 43 tutorial or some gentle introduction, have a look at the AnyEvent::Intro
41 manpage. 44 manpage.
45
46SUPPORT
47 There is a mailinglist for discussing all things AnyEvent, and an IRC
48 channel, too.
49
50 See the AnyEvent project page at the Schmorpforge Ta-Sa Software
51 Repository, at <http://anyevent.schmorp.de>, for more info.
42 52
43WHY YOU SHOULD USE THIS MODULE (OR NOT) 53WHY YOU SHOULD USE THIS MODULE (OR NOT)
44 Glib, POE, IO::Async, Event... CPAN offers event models by the dozen 54 Glib, POE, IO::Async, Event... CPAN offers event models by the dozen
45 nowadays. So what is different about AnyEvent? 55 nowadays. So what is different about AnyEvent?
46 56
… …
166 Note that "my $w; $w =" combination. This is necessary because in Perl, 176 Note that "my $w; $w =" combination. This is necessary because in Perl,
167 my variables are only visible after the statement in which they are 177 my variables are only visible after the statement in which they are
168 declared. 178 declared.
169 179
170 I/O WATCHERS 180 I/O WATCHERS
181 $w = AnyEvent->io (
182 fh => <filehandle_or_fileno>,
183 poll => <"r" or "w">,
184 cb => <callback>,
185 );
186
171 You can create an I/O watcher by calling the "AnyEvent->io" method with 187 You can create an I/O watcher by calling the "AnyEvent->io" method with
172 the following mandatory key-value pairs as arguments: 188 the following mandatory key-value pairs as arguments:
173 189
174 "fh" is the Perl *file handle* (or a naked file descriptor) to watch for 190 "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 191 events (AnyEvent might or might not keep a reference to this file
… …
203 warn "read: $input\n"; 219 warn "read: $input\n";
204 undef $w; 220 undef $w;
205 }); 221 });
206 222
207 TIME WATCHERS 223 TIME WATCHERS
224 $w = AnyEvent->timer (after => <seconds>, cb => <callback>);
225
226 $w = AnyEvent->timer (
227 after => <fractional_seconds>,
228 interval => <fractional_seconds>,
229 cb => <callback>,
230 );
231
208 You can create a time watcher by calling the "AnyEvent->timer" method 232 You can create a time watcher by calling the "AnyEvent->timer" method
209 with the following mandatory arguments: 233 with the following mandatory arguments:
210 234
211 "after" specifies after how many seconds (fractional values are 235 "after" specifies after how many seconds (fractional values are
212 supported) the callback should be invoked. "cb" is the callback to 236 supported) the callback should be invoked. "cb" is the callback to
… …
333 time, which might affect timers and time-outs. 357 time, which might affect timers and time-outs.
334 358
335 When this is the case, you can call this method, which will update 359 When this is the case, you can call this method, which will update
336 the event loop's idea of "current time". 360 the event loop's idea of "current time".
337 361
362 A typical example would be a script in a web server (e.g.
363 "mod_perl") - when mod_perl executes the script, then the event loop
364 will have the wrong idea about the "current time" (being potentially
365 far in the past, when the script ran the last time). In that case
366 you should arrange a call to "AnyEvent->now_update" each time the
367 web server process wakes up again (e.g. at the start of your script,
368 or in a handler).
369
338 Note that updating the time *might* cause some events to be handled. 370 Note that updating the time *might* cause some events to be handled.
339 371
340 SIGNAL WATCHERS 372 SIGNAL WATCHERS
373 $w = AnyEvent->signal (signal => <uppercase_signal_name>, cb => <callback>);
374
341 You can watch for signals using a signal watcher, "signal" is the signal 375 You can watch for signals using a signal watcher, "signal" is the signal
342 *name* in uppercase and without any "SIG" prefix, "cb" is the Perl 376 *name* in uppercase and without any "SIG" prefix, "cb" is the Perl
343 callback to be invoked whenever a signal occurs. 377 callback to be invoked whenever a signal occurs.
344 378
345 Although the callback might get passed parameters, their value and 379 Although the callback might get passed parameters, their value and
… …
357 391
358 This watcher might use %SIG (depending on the event loop used), so 392 This watcher might use %SIG (depending on the event loop used), so
359 programs overwriting those signals directly will likely not work 393 programs overwriting those signals directly will likely not work
360 correctly. 394 correctly.
361 395
396 Example: exit on SIGINT
397
398 my $w = AnyEvent->signal (signal => "INT", cb => sub { exit 1 });
399
400 Restart Behaviour
401 While restart behaviour is up to the event loop implementation, most
402 will not restart syscalls (that includes Async::Interrupt and AnyEvent's
403 pure perl implementation).
404
405 Safe/Unsafe Signals
406 Perl signals can be either "safe" (synchronous to opcode handling) or
407 "unsafe" (asynchronous) - the former might get delayed indefinitely, the
408 latter might corrupt your memory.
409
410 AnyEvent signal handlers are, in addition, synchronous to the event
411 loop, i.e. they will not interrupt your running perl program but will
412 only be called as part of the normal event handling (just like timer,
413 I/O etc. callbacks, too).
414
415 Signal Races, Delays and Workarounds
362 Also note that many event loops (e.g. Glib, Tk, Qt, IO::Async) do not 416 Many event loops (e.g. Glib, Tk, Qt, IO::Async) do not support attaching
363 support attaching callbacks to signals, which is a pity, as you cannot 417 callbacks to signals in a generic way, which is a pity, as you cannot do
364 do race-free signal handling in perl. AnyEvent will try to do it's best, 418 race-free signal handling in perl, requiring C libraries for this.
365 but in some cases, signals will be delayed. The maximum time a signal 419 AnyEvent will try to do it's best, which means in some cases, signals
366 might be delayed is specified in $AnyEvent::MAX_SIGNAL_LATENCY (default: 420 will be delayed. The maximum time a signal might be delayed is specified
367 10 seconds). This variable can be changed only before the first signal 421 in $AnyEvent::MAX_SIGNAL_LATENCY (default: 10 seconds). This variable
368 watcher is created, and should be left alone otherwise. Higher values 422 can be changed only before the first signal watcher is created, and
423 should be left alone otherwise. This variable determines how often
424 AnyEvent polls for signals (in case a wake-up was missed). Higher values
369 will cause fewer spurious wake-ups, which is better for power and CPU 425 will cause fewer spurious wake-ups, which is better for power and CPU
426 saving.
427
370 saving. All these problems can be avoided by installing the optional 428 All these problems can be avoided by installing the optional
371 Async::Interrupt module. 429 Async::Interrupt module, which works with most event loops. It will not
372 430 work with inherently broken event loops such as Event or Event::Lib (and
373 Example: exit on SIGINT 431 not with POE currently, as POE does it's own workaround with one-second
374 432 latency). For those, you just have to suffer the delays.
375 my $w = AnyEvent->signal (signal => "INT", cb => sub { exit 1 });
376 433
377 CHILD PROCESS WATCHERS 434 CHILD PROCESS WATCHERS
435 $w = AnyEvent->child (pid => <process id>, cb => <callback>);
436
378 You can also watch on a child process exit and catch its exit status. 437 You can also watch on a child process exit and catch its exit status.
379 438
380 The child process is specified by the "pid" argument (if set to 0, it 439 The child process is specified by the "pid" argument (one some backends,
381 watches for any child process exit). The watcher will triggered only 440 using 0 watches for any child process exit, on others this will croak).
382 when the child process has finished and an exit status is available, not 441 The watcher will be triggered only when the child process has finished
383 on any trace events (stopped/continued). 442 and an exit status is available, not on any trace events
443 (stopped/continued).
384 444
385 The callback will be called with the pid and exit status (as returned by 445 The callback will be called with the pid and exit status (as returned by
386 waitpid), so unlike other watcher types, you *can* rely on child watcher 446 waitpid), so unlike other watcher types, you *can* rely on child watcher
387 callback arguments. 447 callback arguments.
388 448
… …
427 487
428 # do something else, then wait for process exit 488 # do something else, then wait for process exit
429 $done->recv; 489 $done->recv;
430 490
431 IDLE WATCHERS 491 IDLE WATCHERS
432 Sometimes there is a need to do something, but it is not so important to 492 $w = AnyEvent->idle (cb => <callback>);
433 do it instantly, but only when there is nothing better to do. This
434 "nothing better to do" is usually defined to be "no other events need
435 attention by the event loop".
436 493
437 Idle watchers ideally get invoked when the event loop has nothing better 494 Repeatedly invoke the callback after the process becomes idle, until
438 to do, just before it would block the process to wait for new events. 495 either the watcher is destroyed or new events have been detected.
439 Instead of blocking, the idle watcher is invoked.
440 496
441 Most event loops unfortunately do not really support idle watchers (only 497 Idle watchers are useful when there is a need to do something, but it is
498 not so important (or wise) to do it instantly. The callback will be
499 invoked only when there is "nothing better to do", which is usually
500 defined as "all outstanding events have been handled and no new events
501 have been detected". That means that idle watchers ideally get invoked
502 when the event loop has just polled for new events but none have been
503 detected. Instead of blocking to wait for more events, the idle watchers
504 will be invoked.
505
506 Unfortunately, most event loops do not really support idle watchers
442 EV, Event and Glib do it in a usable fashion) - for the rest, AnyEvent 507 (only EV, Event and Glib do it in a usable fashion) - for the rest,
443 will simply call the callback "from time to time". 508 AnyEvent will simply call the callback "from time to time".
444 509
445 Example: read lines from STDIN, but only process them when the program 510 Example: read lines from STDIN, but only process them when the program
446 is otherwise idle: 511 is otherwise idle:
447 512
448 my @lines; # read data 513 my @lines; # read data
… …
461 } 526 }
462 }); 527 });
463 }); 528 });
464 529
465 CONDITION VARIABLES 530 CONDITION VARIABLES
531 $cv = AnyEvent->condvar;
532
533 $cv->send (<list>);
534 my @res = $cv->recv;
535
466 If you are familiar with some event loops you will know that all of them 536 If you are familiar with some event loops you will know that all of them
467 require you to run some blocking "loop", "run" or similar function that 537 require you to run some blocking "loop", "run" or similar function that
468 will actively watch for new events and call your callbacks. 538 will actively watch for new events and call your callbacks.
469 539
470 AnyEvent is slightly different: it expects somebody else to run the 540 AnyEvent is slightly different: it expects somebody else to run the
471 event loop and will only block when necessary (usually when told by the 541 event loop and will only block when necessary (usually when told by the
472 user). 542 user).
473 543
474 The instrument to do that is called a "condition variable", so called 544 The tool to do that is called a "condition variable", so called because
475 because they represent a condition that must become true. 545 they represent a condition that must become true.
476 546
477 Now is probably a good time to look at the examples further below. 547 Now is probably a good time to look at the examples further below.
478 548
479 Condition variables can be created by calling the "AnyEvent->condvar" 549 Condition variables can be created by calling the "AnyEvent->condvar"
480 method, usually without arguments. The only argument pair allowed is 550 method, usually without arguments. The only argument pair allowed is
… …
485 After creation, the condition variable is "false" until it becomes 555 After creation, the condition variable is "false" until it becomes
486 "true" by calling the "send" method (or calling the condition variable 556 "true" by calling the "send" method (or calling the condition variable
487 as if it were a callback, read about the caveats in the description for 557 as if it were a callback, read about the caveats in the description for
488 the "->send" method). 558 the "->send" method).
489 559
490 Condition variables are similar to callbacks, except that you can 560 Since condition variables are the most complex part of the AnyEvent API,
491 optionally wait for them. They can also be called merge points - points 561 here are some different mental models of what they are - pick the ones
492 in time where multiple outstanding events have been processed. And yet 562 you can connect to:
493 another way to call them is transactions - each condition variable can 563
494 be used to represent a transaction, which finishes at some point and 564 * Condition variables are like callbacks - you can call them (and pass
495 delivers a result. 565 them instead of callbacks). Unlike callbacks however, you can also
566 wait for them to be called.
567
568 * Condition variables are signals - one side can emit or send them,
569 the other side can wait for them, or install a handler that is
570 called when the signal fires.
571
572 * Condition variables are like "Merge Points" - points in your program
573 where you merge multiple independent results/control flows into one.
574
575 * Condition variables represent a transaction - function that start
576 some kind of transaction can return them, leaving the caller the
577 choice between waiting in a blocking fashion, or setting a callback.
578
579 * Condition variables represent future values, or promises to deliver
580 some result, long before the result is available.
496 581
497 Condition variables are very useful to signal that something has 582 Condition variables are very useful to signal that something has
498 finished, for example, if you write a module that does asynchronous http 583 finished, for example, if you write a module that does asynchronous http
499 requests, then a condition variable would be the ideal candidate to 584 requests, then a condition variable would be the ideal candidate to
500 signal the availability of results. The user can either act when the 585 signal the availability of results. The user can either act when the
… …
521 which eventually calls "-> send", and the "consumer side", which waits 606 which eventually calls "-> send", and the "consumer side", which waits
522 for the send to occur. 607 for the send to occur.
523 608
524 Example: wait for a timer. 609 Example: wait for a timer.
525 610
526 # wait till the result is ready 611 # condition: "wait till the timer is fired"
527 my $result_ready = AnyEvent->condvar; 612 my $timer_fired = AnyEvent->condvar;
528 613
529 # do something such as adding a timer 614 # create the timer - we could wait for, say
530 # or socket watcher the calls $result_ready->send 615 # a handle becomign ready, or even an
531 # when the "result" is ready. 616 # AnyEvent::HTTP request to finish, but
532 # in this case, we simply use a timer: 617 # in this case, we simply use a timer:
533 my $w = AnyEvent->timer ( 618 my $w = AnyEvent->timer (
534 after => 1, 619 after => 1,
535 cb => sub { $result_ready->send }, 620 cb => sub { $timer_fired->send },
536 ); 621 );
537 622
538 # this "blocks" (while handling events) till the callback 623 # this "blocks" (while handling events) till the callback
539 # calls -<send 624 # calls ->send
540 $result_ready->recv; 625 $timer_fired->recv;
541 626
542 Example: wait for a timer, but take advantage of the fact that condition 627 Example: wait for a timer, but take advantage of the fact that condition
543 variables are also callable directly. 628 variables are also callable directly.
544 629
545 my $done = AnyEvent->condvar; 630 my $done = AnyEvent->condvar;
… …
601 into one. For example, a function that pings many hosts in parallel 686 into one. For example, a function that pings many hosts in parallel
602 might want to use a condition variable for the whole process. 687 might want to use a condition variable for the whole process.
603 688
604 Every call to "->begin" will increment a counter, and every call to 689 Every call to "->begin" will increment a counter, and every call to
605 "->end" will decrement it. If the counter reaches 0 in "->end", the 690 "->end" will decrement it. If the counter reaches 0 in "->end", the
606 (last) callback passed to "begin" will be executed. That callback is 691 (last) callback passed to "begin" will be executed, passing the
607 *supposed* to call "->send", but that is not required. If no 692 condvar as first argument. That callback is *supposed* to call
693 "->send", but that is not required. If no group callback was set,
608 callback was set, "send" will be called without any arguments. 694 "send" will be called without any arguments.
609 695
610 You can think of "$cv->send" giving you an OR condition (one call 696 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 697 sends), while "$cv->begin" and "$cv->end" giving you an AND
612 condition (all "begin" calls must be "end"'ed before the condvar 698 condition (all "begin" calls must be "end"'ed before the condvar
613 sends). 699 sends).
… …
641 that are begung can potentially be zero: 727 that are begung can potentially be zero:
642 728
643 my $cv = AnyEvent->condvar; 729 my $cv = AnyEvent->condvar;
644 730
645 my %result; 731 my %result;
646 $cv->begin (sub { $cv->send (\%result) }); 732 $cv->begin (sub { shift->send (\%result) });
647 733
648 for my $host (@list_of_hosts) { 734 for my $host (@list_of_hosts) {
649 $cv->begin; 735 $cv->begin;
650 ping_host_then_call_callback $host, sub { 736 ping_host_then_call_callback $host, sub {
651 $result{$host} = ...; 737 $result{$host} = ...;
… …
718 804
719 $cb = $cv->cb ($cb->($cv)) 805 $cb = $cv->cb ($cb->($cv))
720 This is a mutator function that returns the callback set and 806 This is a mutator function that returns the callback set and
721 optionally replaces it before doing so. 807 optionally replaces it before doing so.
722 808
723 The callback will be called when the condition becomes "true", i.e. 809 The callback will be called when the condition becomes (or already
724 when "send" or "croak" are called, with the only argument being the 810 was) "true", i.e. when "send" or "croak" are called (or were
725 condition variable itself. Calling "recv" inside the callback or at 811 called), with the only argument being the condition variable itself.
812 Calling "recv" inside the callback or at any later time is
726 any later time is guaranteed not to block. 813 guaranteed not to block.
727 814
728SUPPORTED EVENT LOOPS/BACKENDS 815SUPPORTED EVENT LOOPS/BACKENDS
729 The available backend classes are (every class has its own manpage): 816 The available backend classes are (every class has its own manpage):
730 817
731 Backends that are autoprobed when no other event loop can be found. 818 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 819 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, 820 use. If EV is not installed, then AnyEvent will fall back to its own
734 failing that, will fall back to its own pure-perl implementation, 821 pure-perl implementation, which is available everywhere as it comes
735 which is available everywhere as it comes with AnyEvent itself. 822 with AnyEvent itself.
736 823
737 AnyEvent::Impl::EV based on EV (interface to libev, best choice). 824 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. 825 AnyEvent::Impl::Perl pure-perl implementation, fast and portable.
740 826
741 Backends that are transparently being picked up when they are used. 827 Backends that are transparently being picked up when they are used.
742 These will be used when they are currently loaded when the first 828 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 829 watcher is created, in which case it is assumed that the application
744 is using them. This means that AnyEvent will automatically pick the 830 is using them. This means that AnyEvent will automatically pick the
745 right backend when the main program loads an event module before 831 right backend when the main program loads an event module before
746 anything starts to create watchers. Nothing special needs to be done 832 anything starts to create watchers. Nothing special needs to be done
747 by the main program. 833 by the main program.
748 834
835 AnyEvent::Impl::Event based on Event, very stable, few glitches.
749 AnyEvent::Impl::Glib based on Glib, slow but very stable. 836 AnyEvent::Impl::Glib based on Glib, slow but very stable.
750 AnyEvent::Impl::Tk based on Tk, very broken. 837 AnyEvent::Impl::Tk based on Tk, very broken.
751 AnyEvent::Impl::EventLib based on Event::Lib, leaks memory and worse. 838 AnyEvent::Impl::EventLib based on Event::Lib, leaks memory and worse.
752 AnyEvent::Impl::POE based on POE, very slow, some limitations. 839 AnyEvent::Impl::POE based on POE, very slow, some limitations.
840 AnyEvent::Impl::Irssi used when running within irssi.
753 841
754 Backends with special needs. 842 Backends with special needs.
755 Qt requires the Qt::Application to be instantiated first, but will 843 Qt requires the Qt::Application to be instantiated first, but will
756 otherwise be picked up automatically. As long as the main program 844 otherwise be picked up automatically. As long as the main program
757 instantiates the application before any AnyEvent watchers are 845 instantiates the application before any AnyEvent watchers are
… …
822 creates and installs the global IO::AIO watcher in a "post_detect" 910 creates and installs the global IO::AIO watcher in a "post_detect"
823 block to avoid autodetecting the event module at load time. 911 block to avoid autodetecting the event module at load time.
824 912
825 If called in scalar or list context, then it creates and returns an 913 If called in scalar or list context, then it creates and returns an
826 object that automatically removes the callback again when it is 914 object that automatically removes the callback again when it is
915 destroyed (or "undef" when the hook was immediately executed). See
827 destroyed. See Coro::BDB for a case where this is useful. 916 AnyEvent::AIO for a case where this is useful.
917
918 Example: Create a watcher for the IO::AIO module and store it in
919 $WATCHER. Only do so after the event loop is initialised, though.
920
921 our WATCHER;
922
923 my $guard = AnyEvent::post_detect {
924 $WATCHER = AnyEvent->io (fh => IO::AIO::poll_fileno, poll => 'r', cb => \&IO::AIO::poll_cb);
925 };
926
927 # the ||= is important in case post_detect immediately runs the block,
928 # as to not clobber the newly-created watcher. assigning both watcher and
929 # post_detect guard to the same variable has the advantage of users being
930 # able to just C<undef $WATCHER> if the watcher causes them grief.
931
932 $WATCHER ||= $guard;
828 933
829 @AnyEvent::post_detect 934 @AnyEvent::post_detect
830 If there are any code references in this array (you can "push" to it 935 If there are any code references in this array (you can "push" to it
831 before or after loading AnyEvent), then they will called directly 936 before or after loading AnyEvent), then they will called directly
832 after the event loop has been chosen. 937 after the event loop has been chosen.
… …
834 You should check $AnyEvent::MODEL before adding to this array, 939 You should check $AnyEvent::MODEL before adding to this array,
835 though: if it is defined then the event loop has already been 940 though: if it is defined then the event loop has already been
836 detected, and the array will be ignored. 941 detected, and the array will be ignored.
837 942
838 Best use "AnyEvent::post_detect { BLOCK }" when your application 943 Best use "AnyEvent::post_detect { BLOCK }" when your application
839 allows it,as it takes care of these details. 944 allows it, as it takes care of these details.
840 945
841 This variable is mainly useful for modules that can do something 946 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 947 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 948 initialised, but do not need to even load it by default. This array
844 provides the means to hook into AnyEvent passively, without loading 949 provides the means to hook into AnyEvent passively, without loading
845 it. 950 it.
951
952 Example: To load Coro::AnyEvent whenever Coro and AnyEvent are used
953 together, you could put this into Coro (this is the actual code used
954 by Coro to accomplish this):
955
956 if (defined $AnyEvent::MODEL) {
957 # AnyEvent already initialised, so load Coro::AnyEvent
958 require Coro::AnyEvent;
959 } else {
960 # AnyEvent not yet initialised, so make sure to load Coro::AnyEvent
961 # as soon as it is
962 push @AnyEvent::post_detect, sub { require Coro::AnyEvent };
963 }
846 964
847WHAT TO DO IN A MODULE 965WHAT TO DO IN A MODULE
848 As a module author, you should "use AnyEvent" and call AnyEvent methods 966 As a module author, you should "use AnyEvent" and call AnyEvent methods
849 freely, but you should not load a specific event module or rely on it. 967 freely, but you should not load a specific event module or rely on it.
850 968
… …
903 1021
904OTHER MODULES 1022OTHER MODULES
905 The following is a non-exhaustive list of additional modules that use 1023 The following is a non-exhaustive list of additional modules that use
906 AnyEvent as a client and can therefore be mixed easily with other 1024 AnyEvent as a client and can therefore be mixed easily with other
907 AnyEvent modules and other event loops in the same program. Some of the 1025 AnyEvent modules and other event loops in the same program. Some of the
908 modules come with AnyEvent, most are available via CPAN. 1026 modules come as part of AnyEvent, the others are available via CPAN.
909 1027
910 AnyEvent::Util 1028 AnyEvent::Util
911 Contains various utility functions that replace often-used but 1029 Contains various utility functions that replace often-used but
912 blocking functions such as "inet_aton" by event-/callback-based 1030 blocking functions such as "inet_aton" by event-/callback-based
913 versions. 1031 versions.
… …
924 transparent and non-blocking SSL/TLS (via AnyEvent::TLS. 1042 transparent and non-blocking SSL/TLS (via AnyEvent::TLS.
925 1043
926 AnyEvent::DNS 1044 AnyEvent::DNS
927 Provides rich asynchronous DNS resolver capabilities. 1045 Provides rich asynchronous DNS resolver capabilities.
928 1046
1047 AnyEvent::HTTP, AnyEvent::IRC, AnyEvent::XMPP, AnyEvent::GPSD,
1048 AnyEvent::IGS, AnyEvent::FCP
1049 Implement event-based interfaces to the protocols of the same name
1050 (for the curious, IGS is the International Go Server and FCP is the
1051 Freenet Client Protocol).
1052
1053 AnyEvent::Handle::UDP
1054 Here be danger!
1055
1056 As Pauli would put it, "Not only is it not right, it's not even
1057 wrong!" - there are so many things wrong with AnyEvent::Handle::UDP,
1058 most notably it's use of a stream-based API with a protocol that
1059 isn't streamable, that the only way to improve it is to delete it.
1060
1061 It features data corruption (but typically only under load) and
1062 general confusion. On top, the author is not only clueless about UDP
1063 but also fact-resistant - some gems of his understanding: "connect
1064 doesn't work with UDP", "UDP packets are not IP packets", "UDP only
1065 has datagrams, not packets", "I don't need to implement proper error
1066 checking as UDP doesn't support error checking" and so on - he
1067 doesn't even understand what's wrong with his module when it is
1068 explained to him.
1069
929 AnyEvent::HTTP 1070 AnyEvent::DBI
930 A simple-to-use HTTP library that is capable of making a lot of 1071 Executes DBI requests asynchronously in a proxy process for you,
931 concurrent HTTP requests. 1072 notifying you in an event-bnased way when the operation is finished.
1073
1074 AnyEvent::AIO
1075 Truly asynchronous (as opposed to non-blocking) I/O, should be in
1076 the toolbox of every event programmer. AnyEvent::AIO transparently
1077 fuses IO::AIO and AnyEvent together, giving AnyEvent access to
1078 event-based file I/O, and much more.
932 1079
933 AnyEvent::HTTPD 1080 AnyEvent::HTTPD
934 Provides a simple web application server framework. 1081 A simple embedded webserver.
935 1082
936 AnyEvent::FastPing 1083 AnyEvent::FastPing
937 The fastest ping in the west. 1084 The fastest ping in the west.
938 1085
939 AnyEvent::DBI
940 Executes DBI requests asynchronously in a proxy process.
941
942 AnyEvent::AIO
943 Truly asynchronous I/O, should be in the toolbox of every event
944 programmer. AnyEvent::AIO transparently fuses IO::AIO and AnyEvent
945 together.
946
947 AnyEvent::BDB
948 Truly asynchronous Berkeley DB access. AnyEvent::BDB transparently
949 fuses BDB and AnyEvent together.
950
951 AnyEvent::GPSD
952 A non-blocking interface to gpsd, a daemon delivering GPS
953 information.
954
955 AnyEvent::IRC
956 AnyEvent based IRC client module family (replacing the older
957 Net::IRC3).
958
959 AnyEvent::XMPP
960 AnyEvent based XMPP (Jabber protocol) module family (replacing the
961 older Net::XMPP2>.
962
963 AnyEvent::IGS
964 A non-blocking interface to the Internet Go Server protocol (used by
965 App::IGS).
966
967 Net::FCP
968 AnyEvent-based implementation of the Freenet Client Protocol,
969 birthplace of AnyEvent.
970
971 Event::ExecFlow
972 High level API for event-based execution flow control.
973
974 Coro 1086 Coro
975 Has special support for AnyEvent via Coro::AnyEvent. 1087 Has special support for AnyEvent via Coro::AnyEvent.
1088
1089SIMPLIFIED AE API
1090 Starting with version 5.0, AnyEvent officially supports a second, much
1091 simpler, API that is designed to reduce the calling, typing and memory
1092 overhead by using function call syntax and a fixed number of parameters.
1093
1094 See the AE manpage for details.
976 1095
977ERROR AND EXCEPTION HANDLING 1096ERROR AND EXCEPTION HANDLING
978 In general, AnyEvent does not do any error handling - it relies on the 1097 In general, AnyEvent does not do any error handling - it relies on the
979 caller to do that if required. The AnyEvent::Strict module (see also the 1098 caller to do that if required. The AnyEvent::Strict module (see also the
980 "PERL_ANYEVENT_STRICT" environment variable, below) provides strict 1099 "PERL_ANYEVENT_STRICT" environment variable, below) provides strict
… …
1159 warn "read: $input\n"; # output what has been read 1278 warn "read: $input\n"; # output what has been read
1160 $cv->send if $input =~ /^q/i; # quit program if /^q/i 1279 $cv->send if $input =~ /^q/i; # quit program if /^q/i
1161 }, 1280 },
1162 ); 1281 );
1163 1282
1164 my $time_watcher; # can only be used once
1165
1166 sub new_timer {
1167 $timer = AnyEvent->timer (after => 1, cb => sub { 1283 my $time_watcher = AnyEvent->timer (after => 1, interval => 1, cb => sub {
1168 warn "timeout\n"; # print 'timeout' about every second 1284 warn "timeout\n"; # print 'timeout' at most every second
1169 &new_timer; # and restart the time
1170 });
1171 } 1285 });
1172
1173 new_timer; # create first timer
1174 1286
1175 $cv->recv; # wait until user enters /^q/i 1287 $cv->recv; # wait until user enters /^q/i
1176 1288
1177REAL-WORLD EXAMPLE 1289REAL-WORLD EXAMPLE
1178 Consider the Net::FCP module. It features (among others) the following 1290 Consider the Net::FCP module. It features (among others) the following
… …
1250 1362
1251 The actual code goes further and collects all errors ("die"s, 1363 The actual code goes further and collects all errors ("die"s,
1252 exceptions) that occurred during request processing. The "result" method 1364 exceptions) that occurred during request processing. The "result" method
1253 detects whether an exception as thrown (it is stored inside the $txn 1365 detects whether an exception as thrown (it is stored inside the $txn
1254 object) and just throws the exception, which means connection errors and 1366 object) and just throws the exception, which means connection errors and
1255 other problems get reported tot he code that tries to use the result, 1367 other problems get reported to the code that tries to use the result,
1256 not in a random callback. 1368 not in a random callback.
1257 1369
1258 All of this enables the following usage styles: 1370 All of this enables the following usage styles:
1259 1371
1260 1. Blocking: 1372 1. Blocking:
… …
1305 through AnyEvent. The benchmark creates a lot of timers (with a zero 1417 through AnyEvent. The benchmark creates a lot of timers (with a zero
1306 timeout) and I/O watchers (watching STDOUT, a pty, to become writable, 1418 timeout) and I/O watchers (watching STDOUT, a pty, to become writable,
1307 which it is), lets them fire exactly once and destroys them again. 1419 which it is), lets them fire exactly once and destroys them again.
1308 1420
1309 Source code for this benchmark is found as eg/bench in the AnyEvent 1421 Source code for this benchmark is found as eg/bench in the AnyEvent
1310 distribution. 1422 distribution. It uses the AE interface, which makes a real difference
1423 for the EV and Perl backends only.
1311 1424
1312 Explanation of the columns 1425 Explanation of the columns
1313 *watcher* is the number of event watchers created/destroyed. Since 1426 *watcher* is the number of event watchers created/destroyed. Since
1314 different event models feature vastly different performances, each event 1427 different event models feature vastly different performances, each event
1315 loop was given a number of watchers so that overall runtime is 1428 loop was given a number of watchers so that overall runtime is
… …
1334 *destroy* is the time, in microseconds, that it takes to destroy a 1447 *destroy* is the time, in microseconds, that it takes to destroy a
1335 single watcher. 1448 single watcher.
1336 1449
1337 Results 1450 Results
1338 name watchers bytes create invoke destroy comment 1451 name watchers bytes create invoke destroy comment
1339 EV/EV 400000 224 0.47 0.35 0.27 EV native interface 1452 EV/EV 100000 223 0.47 0.43 0.27 EV native interface
1340 EV/Any 100000 224 2.88 0.34 0.27 EV + AnyEvent watchers 1453 EV/Any 100000 223 0.48 0.42 0.26 EV + AnyEvent watchers
1341 CoroEV/Any 100000 224 2.85 0.35 0.28 coroutines + Coro::Signal 1454 Coro::EV/Any 100000 223 0.47 0.42 0.26 coroutines + Coro::Signal
1342 Perl/Any 100000 452 4.13 0.73 0.95 pure perl implementation 1455 Perl/Any 100000 431 2.70 0.74 0.92 pure perl implementation
1343 Event/Event 16000 517 32.20 31.80 0.81 Event native interface 1456 Event/Event 16000 516 31.16 31.84 0.82 Event native interface
1344 Event/Any 16000 590 35.85 31.55 1.06 Event + AnyEvent watchers 1457 Event/Any 16000 1203 42.61 34.79 1.80 Event + AnyEvent watchers
1345 IOAsync/Any 16000 989 38.10 32.77 11.13 via IO::Async::Loop::IO_Poll 1458 IOAsync/Any 16000 1911 41.92 27.45 16.81 via IO::Async::Loop::IO_Poll
1346 IOAsync/Any 16000 990 37.59 29.50 10.61 via IO::Async::Loop::Epoll 1459 IOAsync/Any 16000 1726 40.69 26.37 15.25 via IO::Async::Loop::Epoll
1347 Glib/Any 16000 1357 102.33 12.31 51.00 quadratic behaviour 1460 Glib/Any 16000 1118 89.00 12.57 51.17 quadratic behaviour
1348 Tk/Any 2000 1860 27.20 66.31 14.00 SEGV with >> 2000 watchers 1461 Tk/Any 2000 1346 20.96 10.75 8.00 SEGV with >> 2000 watchers
1349 POE/Event 2000 6328 109.99 751.67 14.02 via POE::Loop::Event 1462 POE/Any 2000 6951 108.97 795.32 14.24 via POE::Loop::Event
1350 POE/Select 2000 6027 94.54 809.13 579.80 via POE::Loop::Select 1463 POE/Any 2000 6648 94.79 774.40 575.51 via POE::Loop::Select
1351 1464
1352 Discussion 1465 Discussion
1353 The benchmark does *not* measure scalability of the event loop very 1466 The benchmark does *not* measure scalability of the event loop very
1354 well. For example, a select-based event loop (such as the pure perl one) 1467 well. For example, a select-based event loop (such as the pure perl one)
1355 can never compete with an event loop that uses epoll when the number of 1468 can never compete with an event loop that uses epoll when the number of
… …
1366 benchmark machine, handling an event takes roughly 1600 CPU cycles with 1479 benchmark machine, handling an event takes roughly 1600 CPU cycles with
1367 EV, 3100 CPU cycles with AnyEvent's pure perl loop and almost 3000000 1480 EV, 3100 CPU cycles with AnyEvent's pure perl loop and almost 3000000
1368 CPU cycles with POE. 1481 CPU cycles with POE.
1369 1482
1370 "EV" is the sole leader regarding speed and memory use, which are both 1483 "EV" is the sole leader regarding speed and memory use, which are both
1371 maximal/minimal, respectively. Even when going through AnyEvent, it uses 1484 maximal/minimal, respectively. When using the AE API there is zero
1485 overhead (when going through the AnyEvent API create is about 5-6 times
1486 slower, with other times being equal, so still uses far less memory than
1372 far less memory than any other event loop and is still faster than Event 1487 any other event loop and is still faster than Event natively).
1373 natively.
1374 1488
1375 The pure perl implementation is hit in a few sweet spots (both the 1489 The pure perl implementation is hit in a few sweet spots (both the
1376 constant timeout and the use of a single fd hit optimisations in the 1490 constant timeout and the use of a single fd hit optimisations in the
1377 perl interpreter and the backend itself). Nevertheless this shows that 1491 perl interpreter and the backend itself). Nevertheless this shows that
1378 it adds very little overhead in itself. Like any select-based backend 1492 it adds very little overhead in itself. Like any select-based backend
… …
1448 In this benchmark, we use 10000 socket pairs (20000 sockets), of which 1562 In this benchmark, we use 10000 socket pairs (20000 sockets), of which
1449 100 (1%) are active. This mirrors the activity of large servers with 1563 100 (1%) are active. This mirrors the activity of large servers with
1450 many connections, most of which are idle at any one point in time. 1564 many connections, most of which are idle at any one point in time.
1451 1565
1452 Source code for this benchmark is found as eg/bench2 in the AnyEvent 1566 Source code for this benchmark is found as eg/bench2 in the AnyEvent
1453 distribution. 1567 distribution. It uses the AE interface, which makes a real difference
1568 for the EV and Perl backends only.
1454 1569
1455 Explanation of the columns 1570 Explanation of the columns
1456 *sockets* is the number of sockets, and twice the number of "servers" 1571 *sockets* is the number of sockets, and twice the number of "servers"
1457 (as each server has a read and write socket end). 1572 (as each server has a read and write socket end).
1458 1573
… …
1464 forwarding it to another server. This includes deleting the old timeout 1579 forwarding it to another server. This includes deleting the old timeout
1465 and creating a new one that moves the timeout into the future. 1580 and creating a new one that moves the timeout into the future.
1466 1581
1467 Results 1582 Results
1468 name sockets create request 1583 name sockets create request
1469 EV 20000 69.01 11.16 1584 EV 20000 62.66 7.99
1470 Perl 20000 73.32 35.87 1585 Perl 20000 68.32 32.64
1471 IOAsync 20000 157.00 98.14 epoll 1586 IOAsync 20000 174.06 101.15 epoll
1472 IOAsync 20000 159.31 616.06 poll 1587 IOAsync 20000 174.67 610.84 poll
1473 Event 20000 212.62 257.32 1588 Event 20000 202.69 242.91
1474 Glib 20000 651.16 1896.30 1589 Glib 20000 557.01 1689.52
1475 POE 20000 349.67 12317.24 uses POE::Loop::Event 1590 POE 20000 341.54 12086.32 uses POE::Loop::Event
1476 1591
1477 Discussion 1592 Discussion
1478 This benchmark *does* measure scalability and overall performance of the 1593 This benchmark *does* measure scalability and overall performance of the
1479 particular event loop. 1594 particular event loop.
1480 1595
… …
1593 As you can see, the AnyEvent + EV combination even beats the 1708 As you can see, the AnyEvent + EV combination even beats the
1594 hand-optimised "raw sockets benchmark", while AnyEvent + its pure perl 1709 hand-optimised "raw sockets benchmark", while AnyEvent + its pure perl
1595 backend easily beats IO::Lambda and POE. 1710 backend easily beats IO::Lambda and POE.
1596 1711
1597 And even the 100% non-blocking version written using the high-level (and 1712 And even the 100% non-blocking version written using the high-level (and
1598 slow :) AnyEvent::Handle abstraction beats both POE and IO::Lambda by a 1713 slow :) AnyEvent::Handle abstraction beats both POE and IO::Lambda
1599 large margin, even though it does all of DNS, tcp-connect and socket I/O 1714 higher level ("unoptimised") abstractions by a large margin, even though
1600 in a non-blocking way. 1715 it does all of DNS, tcp-connect and socket I/O in a non-blocking way.
1601 1716
1602 The two AnyEvent benchmarks programs can be found as eg/ae0.pl and 1717 The two AnyEvent benchmarks programs can be found as eg/ae0.pl and
1603 eg/ae2.pl in the AnyEvent distribution, the remaining benchmarks are 1718 eg/ae2.pl in the AnyEvent distribution, the remaining benchmarks are
1604 part of the IO::lambda distribution and were used without any changes. 1719 part of the IO::Lambda distribution and were used without any changes.
1605 1720
1606SIGNALS 1721SIGNALS
1607 AnyEvent currently installs handlers for these signals: 1722 AnyEvent currently installs handlers for these signals:
1608 1723
1609 SIGCHLD 1724 SIGCHLD
… …
1636 it's built-in modules) are required to use it. 1751 it's built-in modules) are required to use it.
1637 1752
1638 That does not mean that AnyEvent won't take advantage of some additional 1753 That does not mean that AnyEvent won't take advantage of some additional
1639 modules if they are installed. 1754 modules if they are installed.
1640 1755
1641 This section epxlains which additional modules will be used, and how 1756 This section explains which additional modules will be used, and how
1642 they affect AnyEvent's operetion. 1757 they affect AnyEvent's operation.
1643 1758
1644 Async::Interrupt 1759 Async::Interrupt
1645 This slightly arcane module is used to implement fast signal 1760 This slightly arcane module is used to implement fast signal
1646 handling: To my knowledge, there is no way to do completely 1761 handling: To my knowledge, there is no way to do completely
1647 race-free and quick signal handling in pure perl. To ensure that 1762 race-free and quick signal handling in pure perl. To ensure that
1648 signals still get delivered, AnyEvent will start an interval timer 1763 signals still get delivered, AnyEvent will start an interval timer
1649 to wake up perl (and catch the signals) with soemd elay (default is 1764 to wake up perl (and catch the signals) with some delay (default is
1650 10 seconds, look for $AnyEvent::MAX_SIGNAL_LATENCY). 1765 10 seconds, look for $AnyEvent::MAX_SIGNAL_LATENCY).
1651 1766
1652 If this module is available, then it will be used to implement 1767 If this module is available, then it will be used to implement
1653 signal catching, which means that signals will not be delayed, and 1768 signal catching, which means that signals will not be delayed, and
1654 the event loop will not be interrupted regularly, which is more 1769 the event loop will not be interrupted regularly, which is more
1655 efficient (And good for battery life on laptops). 1770 efficient (and good for battery life on laptops).
1656 1771
1657 This affects not just the pure-perl event loop, but also other event 1772 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). 1773 loops that have no signal handling on their own (e.g. Glib, Tk, Qt).
1774
1775 Some event loops (POE, Event, Event::Lib) offer signal watchers
1776 natively, and either employ their own workarounds (POE) or use
1777 AnyEvent's workaround (using $AnyEvent::MAX_SIGNAL_LATENCY).
1778 Installing Async::Interrupt does nothing for those backends.
1659 1779
1660 EV This module isn't really "optional", as it is simply one of the 1780 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 1781 backend event loops that AnyEvent can use. However, it is simply the
1662 best event loop available in terms of features, speed and stability: 1782 best event loop available in terms of features, speed and stability:
1663 It supports the AnyEvent API optimally, implements all the watcher 1783 It supports the AnyEvent API optimally, implements all the watcher
… …
1665 clock is available, can take avdantage of advanced kernel interfaces 1785 clock is available, can take avdantage of advanced kernel interfaces
1666 such as "epoll" and "kqueue", and is the fastest backend *by far*. 1786 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 1787 You can even embed Glib/Gtk2 in it (or vice versa, see EV::Glib and
1668 Glib::EV). 1788 Glib::EV).
1669 1789
1790 If you only use backends that rely on another event loop (e.g.
1791 "Tk"), then this module will do nothing for you.
1792
1670 Guard 1793 Guard
1671 The guard module, when used, will be used to implement 1794 The guard module, when used, will be used to implement
1672 "AnyEvent::Util::guard". This speeds up guards considerably (and 1795 "AnyEvent::Util::guard". This speeds up guards considerably (and
1673 uses a lot less memory), but otherwise doesn't affect guard 1796 uses a lot less memory), but otherwise doesn't affect guard
1674 operation much. It is purely used for performance. 1797 operation much. It is purely used for performance.
1675 1798
1676 JSON and JSON::XS 1799 JSON and JSON::XS
1677 This module is required when you want to read or write JSON data via 1800 One of these modules is required when you want to read or write JSON
1678 AnyEvent::Handle. It is also written in pure-perl, but can take 1801 data via AnyEvent::Handle. JSON is also written in pure-perl, but
1679 advantage of the ulta-high-speed JSON::XS module when it is 1802 can take advantage of the ultra-high-speed JSON::XS module when it
1680 installed. 1803 is installed.
1681
1682 In fact, AnyEvent::Handle will use JSON::XS by default if it is
1683 installed.
1684 1804
1685 Net::SSLeay 1805 Net::SSLeay
1686 Implementing TLS/SSL in Perl is certainly interesting, but not very 1806 Implementing TLS/SSL in Perl is certainly interesting, but not very
1687 worthwhile: If this module is installed, then AnyEvent::Handle (with 1807 worthwhile: If this module is installed, then AnyEvent::Handle (with
1688 the help of AnyEvent::TLS), gains the ability to do TLS/SSL. 1808 the help of AnyEvent::TLS), gains the ability to do TLS/SSL.
… …
1694 additionally use it to try to use a monotonic clock for timing 1814 additionally use it to try to use a monotonic clock for timing
1695 stability. 1815 stability.
1696 1816
1697FORK 1817FORK
1698 Most event libraries are not fork-safe. The ones who are usually are 1818 Most event libraries are not fork-safe. The ones who are usually are
1699 because they rely on inefficient but fork-safe "select" or "poll" calls. 1819 because they rely on inefficient but fork-safe "select" or "poll" calls
1700 Only EV is fully fork-aware. 1820 - higher performance APIs such as BSD's kqueue or the dreaded Linux
1821 epoll are usually badly thought-out hacks that are incompatible with
1822 fork in one way or another. Only EV is fully fork-aware and ensures that
1823 you continue event-processing in both parent and child (or both, if you
1824 know what you are doing).
1825
1826 This means that, in general, you cannot fork and do event processing in
1827 the child if the event library was initialised before the fork (which
1828 usually happens when the first AnyEvent watcher is created, or the
1829 library is loaded).
1701 1830
1702 If you have to fork, you must either do so *before* creating your first 1831 If you have to fork, you must either do so *before* creating your first
1703 watcher OR you must not use AnyEvent at all in the child OR you must do 1832 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. 1833 something completely out of the scope of AnyEvent.
1834
1835 The problem of doing event processing in the parent *and* the child is
1836 much more complicated: even for backends that *are* fork-aware or
1837 fork-safe, their behaviour is not usually what you want: fork clones all
1838 watchers, that means all timers, I/O watchers etc. are active in both
1839 parent and child, which is almost never what you want. USing "exec" to
1840 start worker children from some kind of manage rprocess is usually
1841 preferred, because it is much easier and cleaner, at the expense of
1842 having to have another binary.
1705 1843
1706SECURITY CONSIDERATIONS 1844SECURITY CONSIDERATIONS
1707 AnyEvent can be forced to load any event model via 1845 AnyEvent can be forced to load any event model via
1708 $ENV{PERL_ANYEVENT_MODEL}. While this cannot (to my knowledge) be used 1846 $ENV{PERL_ANYEVENT_MODEL}. While this cannot (to my knowledge) be used
1709 to execute arbitrary code or directly gain access, it can easily be used 1847 to execute arbitrary code or directly gain access, it can easily be used
… …
1741 Event::Lib, Qt, POE. 1879 Event::Lib, Qt, POE.
1742 1880
1743 Implementations: AnyEvent::Impl::EV, AnyEvent::Impl::Event, 1881 Implementations: AnyEvent::Impl::EV, AnyEvent::Impl::Event,
1744 AnyEvent::Impl::Glib, AnyEvent::Impl::Tk, AnyEvent::Impl::Perl, 1882 AnyEvent::Impl::Glib, AnyEvent::Impl::Tk, AnyEvent::Impl::Perl,
1745 AnyEvent::Impl::EventLib, AnyEvent::Impl::Qt, AnyEvent::Impl::POE, 1883 AnyEvent::Impl::EventLib, AnyEvent::Impl::Qt, AnyEvent::Impl::POE,
1746 AnyEvent::Impl::IOAsync. 1884 AnyEvent::Impl::IOAsync, Anyevent::Impl::Irssi.
1747 1885
1748 Non-blocking file handles, sockets, TCP clients and servers: 1886 Non-blocking file handles, sockets, TCP clients and servers:
1749 AnyEvent::Handle, AnyEvent::Socket, AnyEvent::TLS. 1887 AnyEvent::Handle, AnyEvent::Socket, AnyEvent::TLS.
1750 1888
1751 Asynchronous DNS: AnyEvent::DNS. 1889 Asynchronous DNS: AnyEvent::DNS.

Diff Legend

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