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

Comparing AnyEvent/README (file contents):
Revision 1.42 by root, Mon Jun 29 21:00:32 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* (*not* 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
176 handle). Note that only file handles pointing to things for which 192 handle). Note that only file handles pointing to things for which
177 non-blocking operation makes sense are allowed. This includes sockets, 193 non-blocking operation makes sense are allowed. This includes sockets,
178 most character devices, pipes, fifos and so on, but not for example 194 most character devices, pipes, fifos and so on, but not for example
179 files or block devices. 195 files or block devices.
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
350 invocation, and callback invocation will be synchronous. Synchronous 384 invocation, and callback invocation will be synchronous. Synchronous
351 means that it might take a while until the signal gets handled by the 385 means that it might take a while until the signal gets handled by the
352 process, but it is guaranteed not to interrupt any other callbacks. 386 process, but it is guaranteed not to interrupt any other callbacks.
353 387
354 The main advantage of using these watchers is that you can share a 388 The main advantage of using these watchers is that you can share a
355 signal between multiple watchers. 389 signal between multiple watchers, and AnyEvent will ensure that signals
390 will not interrupt your program at bad times.
356 391
357 This watcher might use %SIG, so programs overwriting those signals 392 This watcher might use %SIG (depending on the event loop used), so
358 directly will likely not work correctly. 393 programs overwriting those signals directly will likely not work
394 correctly.
359 395
360 Example: exit on SIGINT 396 Example: exit on SIGINT
361 397
362 my $w = AnyEvent->signal (signal => "INT", cb => sub { exit 1 }); 398 my $w = AnyEvent->signal (signal => "INT", cb => sub { exit 1 });
363 399
400 Restart Behaviour
401 While restart behaviour is up to the event loop implementation, most
402 will not restart syscalls (that includes Async::Interrupt and AnyEvent's
403 pure perl implementation).
404
405 Safe/Unsafe Signals
406 Perl signals can be either "safe" (synchronous to opcode handling) or
407 "unsafe" (asynchronous) - the former might get delayed indefinitely, the
408 latter might corrupt your memory.
409
410 AnyEvent signal handlers are, in addition, synchronous to the event
411 loop, i.e. they will not interrupt your running perl program but will
412 only be called as part of the normal event handling (just like timer,
413 I/O etc. callbacks, too).
414
415 Signal Races, Delays and Workarounds
416 Many event loops (e.g. Glib, Tk, Qt, IO::Async) do not support attaching
417 callbacks to signals in a generic way, which is a pity, as you cannot do
418 race-free signal handling in perl, requiring C libraries for this.
419 AnyEvent will try to do it's best, which means in some cases, signals
420 will be delayed. The maximum time a signal might be delayed is specified
421 in $AnyEvent::MAX_SIGNAL_LATENCY (default: 10 seconds). This variable
422 can be changed only before the first signal watcher is created, and
423 should be left alone otherwise. This variable determines how often
424 AnyEvent polls for signals (in case a wake-up was missed). Higher values
425 will cause fewer spurious wake-ups, which is better for power and CPU
426 saving.
427
428 All these problems can be avoided by installing the optional
429 Async::Interrupt module, which works with most event loops. It will not
430 work with inherently broken event loops such as Event or Event::Lib (and
431 not with POE currently, as POE does it's own workaround with one-second
432 latency). For those, you just have to suffer the delays.
433
364 CHILD PROCESS WATCHERS 434 CHILD PROCESS WATCHERS
435 $w = AnyEvent->child (pid => <process id>, cb => <callback>);
436
365 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.
366 438
367 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,
368 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).
369 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
370 on any trace events (stopped/continued). 442 and an exit status is available, not on any trace events
443 (stopped/continued).
371 444
372 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
373 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
374 callback arguments. 447 callback arguments.
375 448
390 of when you start the watcher. 463 of when you start the watcher.
391 464
392 This means you cannot create a child watcher as the very first thing in 465 This means you cannot create a child watcher as the very first thing in
393 an AnyEvent program, you *have* to create at least one watcher before 466 an AnyEvent program, you *have* to create at least one watcher before
394 you "fork" the child (alternatively, you can call "AnyEvent::detect"). 467 you "fork" the child (alternatively, you can call "AnyEvent::detect").
468
469 As most event loops do not support waiting for child events, they will
470 be emulated by AnyEvent in most cases, in which the latency and race
471 problems mentioned in the description of signal watchers apply.
395 472
396 Example: fork a process and wait for it 473 Example: fork a process and wait for it
397 474
398 my $done = AnyEvent->condvar; 475 my $done = AnyEvent->condvar;
399 476
410 487
411 # do something else, then wait for process exit 488 # do something else, then wait for process exit
412 $done->recv; 489 $done->recv;
413 490
414 IDLE WATCHERS 491 IDLE WATCHERS
415 Sometimes there is a need to do something, but it is not so important to 492 $w = AnyEvent->idle (cb => <callback>);
416 do it instantly, but only when there is nothing better to do. This
417 "nothing better to do" is usually defined to be "no other events need
418 attention by the event loop".
419 493
420 Idle watchers ideally get invoked when the event loop has nothing better 494 Repeatedly invoke the callback after the process becomes idle, until
421 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.
422 Instead of blocking, the idle watcher is invoked.
423 496
424 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
425 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,
426 will simply call the callback "from time to time". 508 AnyEvent will simply call the callback "from time to time".
427 509
428 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
429 is otherwise idle: 511 is otherwise idle:
430 512
431 my @lines; # read data 513 my @lines; # read data
444 } 526 }
445 }); 527 });
446 }); 528 });
447 529
448 CONDITION VARIABLES 530 CONDITION VARIABLES
531 $cv = AnyEvent->condvar;
532
533 $cv->send (<list>);
534 my @res = $cv->recv;
535
449 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
450 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
451 will actively watch for new events and call your callbacks. 538 will actively watch for new events and call your callbacks.
452 539
453 AnyEvent is different, it expects somebody else to run the event loop 540 AnyEvent is slightly different: it expects somebody else to run the
454 and will only block when necessary (usually when told by the user). 541 event loop and will only block when necessary (usually when told by the
542 user).
455 543
456 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
457 because they represent a condition that must become true. 545 they represent a condition that must become true.
546
547 Now is probably a good time to look at the examples further below.
458 548
459 Condition variables can be created by calling the "AnyEvent->condvar" 549 Condition variables can be created by calling the "AnyEvent->condvar"
460 method, usually without arguments. The only argument pair allowed is 550 method, usually without arguments. The only argument pair allowed is
461
462 "cb", which specifies a callback to be called when the condition 551 "cb", which specifies a callback to be called when the condition
463 variable becomes true, with the condition variable as the first argument 552 variable becomes true, with the condition variable as the first argument
464 (but not the results). 553 (but not the results).
465 554
466 After creation, the condition variable is "false" until it becomes 555 After creation, the condition variable is "false" until it becomes
467 "true" by calling the "send" method (or calling the condition variable 556 "true" by calling the "send" method (or calling the condition variable
468 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
469 the "->send" method). 558 the "->send" method).
470 559
471 Condition variables are similar to callbacks, except that you can 560 Since condition variables are the most complex part of the AnyEvent API,
472 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
473 in time where multiple outstanding events have been processed. And yet 562 you can connect to:
474 another way to call them is transactions - each condition variable can 563
475 be used to represent a transaction, which finishes at some point and 564 * Condition variables are like callbacks - you can call them (and pass
476 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.
477 581
478 Condition variables are very useful to signal that something has 582 Condition variables are very useful to signal that something has
479 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
480 requests, then a condition variable would be the ideal candidate to 584 requests, then a condition variable would be the ideal candidate to
481 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
502 which eventually calls "-> send", and the "consumer side", which waits 606 which eventually calls "-> send", and the "consumer side", which waits
503 for the send to occur. 607 for the send to occur.
504 608
505 Example: wait for a timer. 609 Example: wait for a timer.
506 610
507 # wait till the result is ready 611 # condition: "wait till the timer is fired"
508 my $result_ready = AnyEvent->condvar; 612 my $timer_fired = AnyEvent->condvar;
509 613
510 # do something such as adding a timer 614 # create the timer - we could wait for, say
511 # or socket watcher the calls $result_ready->send 615 # a handle becomign ready, or even an
512 # when the "result" is ready. 616 # AnyEvent::HTTP request to finish, but
513 # in this case, we simply use a timer: 617 # in this case, we simply use a timer:
514 my $w = AnyEvent->timer ( 618 my $w = AnyEvent->timer (
515 after => 1, 619 after => 1,
516 cb => sub { $result_ready->send }, 620 cb => sub { $timer_fired->send },
517 ); 621 );
518 622
519 # this "blocks" (while handling events) till the callback 623 # this "blocks" (while handling events) till the callback
520 # calls send 624 # calls ->send
521 $result_ready->recv; 625 $timer_fired->recv;
522 626
523 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
524 variables are also code references. 628 variables are also callable directly.
525 629
526 my $done = AnyEvent->condvar; 630 my $done = AnyEvent->condvar;
527 my $delay = AnyEvent->timer (after => 5, cb => $done); 631 my $delay = AnyEvent->timer (after => 5, cb => $done);
528 $done->recv; 632 $done->recv;
529 633
535 639
536 ... 640 ...
537 641
538 my @info = $couchdb->info->recv; 642 my @info = $couchdb->info->recv;
539 643
540 And this is how you would just ste a callback to be called whenever the 644 And this is how you would just set a callback to be called whenever the
541 results are available: 645 results are available:
542 646
543 $couchdb->info->cb (sub { 647 $couchdb->info->cb (sub {
544 my @info = $_[0]->recv; 648 my @info = $_[0]->recv;
545 }); 649 });
560 664
561 Any arguments passed to the "send" call will be returned by all 665 Any arguments passed to the "send" call will be returned by all
562 future "->recv" calls. 666 future "->recv" calls.
563 667
564 Condition variables are overloaded so one can call them directly (as 668 Condition variables are overloaded so one can call them directly (as
565 a code reference). Calling them directly is the same as calling 669 if they were a code reference). Calling them directly is the same as
566 "send". Note, however, that many C-based event loops do not handle 670 calling "send".
567 overloading, so as tempting as it may be, passing a condition
568 variable instead of a callback does not work. Both the pure perl and
569 EV loops support overloading, however, as well as all functions that
570 use perl to invoke a callback (as in AnyEvent::Socket and
571 AnyEvent::DNS for example).
572 671
573 $cv->croak ($error) 672 $cv->croak ($error)
574 Similar to send, but causes all call's to "->recv" to invoke 673 Similar to send, but causes all call's to "->recv" to invoke
575 "Carp::croak" with the given error message/object/scalar. 674 "Carp::croak" with the given error message/object/scalar.
576 675
577 This can be used to signal any errors to the condition variable 676 This can be used to signal any errors to the condition variable
578 user/consumer. 677 user/consumer. Doing it this way instead of calling "croak" directly
678 delays the error detetcion, but has the overwhelmign advantage that
679 it diagnoses the error at the place where the result is expected,
680 and not deep in some event clalback without connection to the actual
681 code causing the problem.
579 682
580 $cv->begin ([group callback]) 683 $cv->begin ([group callback])
581 $cv->end 684 $cv->end
582 These two methods can be used to combine many transactions/events 685 These two methods can be used to combine many transactions/events
583 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
584 might want to use a condition variable for the whole process. 687 might want to use a condition variable for the whole process.
585 688
586 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
587 "->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
588 (last) callback passed to "begin" will be executed. That callback is 691 (last) callback passed to "begin" will be executed, passing the
589 *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,
590 callback was set, "send" will be called without any arguments. 694 "send" will be called without any arguments.
591 695
592 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
593 sends), while "$cv->begin" and "$cv->end" giving you an AND 697 sends), while "$cv->begin" and "$cv->end" giving you an AND
594 condition (all "begin" calls must be "end"'ed before the condvar 698 condition (all "begin" calls must be "end"'ed before the condvar
595 sends). 699 sends).
623 that are begung can potentially be zero: 727 that are begung can potentially be zero:
624 728
625 my $cv = AnyEvent->condvar; 729 my $cv = AnyEvent->condvar;
626 730
627 my %result; 731 my %result;
628 $cv->begin (sub { $cv->send (\%result) }); 732 $cv->begin (sub { shift->send (\%result) });
629 733
630 for my $host (@list_of_hosts) { 734 for my $host (@list_of_hosts) {
631 $cv->begin; 735 $cv->begin;
632 ping_host_then_call_callback $host, sub { 736 ping_host_then_call_callback $host, sub {
633 $result{$host} = ...; 737 $result{$host} = ...;
671 function will call "croak". 775 function will call "croak".
672 776
673 In list context, all parameters passed to "send" will be returned, 777 In list context, all parameters passed to "send" will be returned,
674 in scalar context only the first one will be returned. 778 in scalar context only the first one will be returned.
675 779
780 Note that doing a blocking wait in a callback is not supported by
781 any event loop, that is, recursive invocation of a blocking "->recv"
782 is not allowed, and the "recv" call will "croak" if such a condition
783 is detected. This condition can be slightly loosened by using
784 Coro::AnyEvent, which allows you to do a blocking "->recv" from any
785 thread that doesn't run the event loop itself.
786
676 Not all event models support a blocking wait - some die in that case 787 Not all event models support a blocking wait - some die in that case
677 (programs might want to do that to stay interactive), so *if you are 788 (programs might want to do that to stay interactive), so *if you are
678 using this from a module, never require a blocking wait*, but let 789 using this from a module, never require a blocking wait*. Instead,
679 the caller decide whether the call will block or not (for example, 790 let the caller decide whether the call will block or not (for
680 by coupling condition variables with some kind of request results 791 example, by coupling condition variables with some kind of request
681 and supporting callbacks so the caller knows that getting the result 792 results and supporting callbacks so the caller knows that getting
682 will not block, while still supporting blocking waits if the caller 793 the result will not block, while still supporting blocking waits if
683 so desires). 794 the caller so desires).
684
685 Another reason *never* to "->recv" in a module is that you cannot
686 sensibly have two "->recv"'s in parallel, as that would require
687 multiple interpreters or coroutines/threads, none of which
688 "AnyEvent" can supply.
689
690 The Coro module, however, *can* and *does* supply coroutines and, in
691 fact, Coro::AnyEvent replaces AnyEvent's condvars by coroutine-safe
692 versions and also integrates coroutines into AnyEvent, making
693 blocking "->recv" calls perfectly safe as long as they are done from
694 another coroutine (one that doesn't run the event loop).
695 795
696 You can ensure that "-recv" never blocks by setting a callback and 796 You can ensure that "-recv" never blocks by setting a callback and
697 only calling "->recv" from within that callback (or at a later 797 only calling "->recv" from within that callback (or at a later
698 time). This will work even when the event loop does not support 798 time). This will work even when the event loop does not support
699 blocking waits otherwise. 799 blocking waits otherwise.
704 804
705 $cb = $cv->cb ($cb->($cv)) 805 $cb = $cv->cb ($cb->($cv))
706 This is a mutator function that returns the callback set and 806 This is a mutator function that returns the callback set and
707 optionally replaces it before doing so. 807 optionally replaces it before doing so.
708 808
709 The callback will be called when the condition becomes "true", i.e. 809 The callback will be called when the condition becomes (or already
710 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
711 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
712 any later time is guaranteed not to block. 813 guaranteed not to block.
814
815SUPPORTED EVENT LOOPS/BACKENDS
816 The available backend classes are (every class has its own manpage):
817
818 Backends that are autoprobed when no other event loop can be found.
819 EV is the preferred backend when no other event loop seems to be in
820 use. If EV is not installed, then AnyEvent will fall back to its own
821 pure-perl implementation, which is available everywhere as it comes
822 with AnyEvent itself.
823
824 AnyEvent::Impl::EV based on EV (interface to libev, best choice).
825 AnyEvent::Impl::Perl pure-perl implementation, fast and portable.
826
827 Backends that are transparently being picked up when they are used.
828 These will be used when they are currently loaded when the first
829 watcher is created, in which case it is assumed that the application
830 is using them. This means that AnyEvent will automatically pick the
831 right backend when the main program loads an event module before
832 anything starts to create watchers. Nothing special needs to be done
833 by the main program.
834
835 AnyEvent::Impl::Event based on Event, very stable, few glitches.
836 AnyEvent::Impl::Glib based on Glib, slow but very stable.
837 AnyEvent::Impl::Tk based on Tk, very broken.
838 AnyEvent::Impl::EventLib based on Event::Lib, leaks memory and worse.
839 AnyEvent::Impl::POE based on POE, very slow, some limitations.
840 AnyEvent::Impl::Irssi used when running within irssi.
841
842 Backends with special needs.
843 Qt requires the Qt::Application to be instantiated first, but will
844 otherwise be picked up automatically. As long as the main program
845 instantiates the application before any AnyEvent watchers are
846 created, everything should just work.
847
848 AnyEvent::Impl::Qt based on Qt.
849
850 Support for IO::Async can only be partial, as it is too broken and
851 architecturally limited to even support the AnyEvent API. It also is
852 the only event loop that needs the loop to be set explicitly, so it
853 can only be used by a main program knowing about AnyEvent. See
854 AnyEvent::Impl::Async for the gory details.
855
856 AnyEvent::Impl::IOAsync based on IO::Async, cannot be autoprobed.
857
858 Event loops that are indirectly supported via other backends.
859 Some event loops can be supported via other modules:
860
861 There is no direct support for WxWidgets (Wx) or Prima.
862
863 WxWidgets has no support for watching file handles. However, you can
864 use WxWidgets through the POE adaptor, as POE has a Wx backend that
865 simply polls 20 times per second, which was considered to be too
866 horrible to even consider for AnyEvent.
867
868 Prima is not supported as nobody seems to be using it, but it has a
869 POE backend, so it can be supported through POE.
870
871 AnyEvent knows about both Prima and Wx, however, and will try to
872 load POE when detecting them, in the hope that POE will pick them
873 up, in which case everything will be automatic.
713 874
714GLOBAL VARIABLES AND FUNCTIONS 875GLOBAL VARIABLES AND FUNCTIONS
876 These are not normally required to use AnyEvent, but can be useful to
877 write AnyEvent extension modules.
878
715 $AnyEvent::MODEL 879 $AnyEvent::MODEL
716 Contains "undef" until the first watcher is being created. Then it 880 Contains "undef" until the first watcher is being created, before
881 the backend has been autodetected.
882
717 contains the event model that is being used, which is the name of 883 Afterwards it contains the event model that is being used, which is
718 the Perl class implementing the model. This class is usually one of 884 the name of the Perl class implementing the model. This class is
719 the "AnyEvent::Impl:xxx" modules, but can be any other class in the 885 usually one of the "AnyEvent::Impl:xxx" modules, but can be any
720 case AnyEvent has been extended at runtime (e.g. in *rxvt-unicode*). 886 other class in the case AnyEvent has been extended at runtime (e.g.
721 887 in *rxvt-unicode* it will be "urxvt::anyevent").
722 The known classes so far are:
723
724 AnyEvent::Impl::EV based on EV (an interface to libev, best choice).
725 AnyEvent::Impl::Event based on Event, second best choice.
726 AnyEvent::Impl::Perl pure-perl implementation, fast and portable.
727 AnyEvent::Impl::Glib based on Glib, third-best choice.
728 AnyEvent::Impl::Tk based on Tk, very bad choice.
729 AnyEvent::Impl::Qt based on Qt, cannot be autoprobed (see its docs).
730 AnyEvent::Impl::EventLib based on Event::Lib, leaks memory and worse.
731 AnyEvent::Impl::POE based on POE, not generic enough for full support.
732
733 # warning, support for IO::Async is only partial, as it is too broken
734 # and limited toe ven support the AnyEvent API. See AnyEvent::Impl::Async.
735 AnyEvent::Impl::IOAsync based on IO::Async, cannot be autoprobed (see its docs).
736
737 There is no support for WxWidgets, as WxWidgets has no support for
738 watching file handles. However, you can use WxWidgets through the
739 POE Adaptor, as POE has a Wx backend that simply polls 20 times per
740 second, which was considered to be too horrible to even consider for
741 AnyEvent. Likewise, other POE backends can be used by AnyEvent by
742 using it's adaptor.
743
744 AnyEvent knows about Prima and Wx and will try to use POE when
745 autodetecting them.
746 888
747 AnyEvent::detect 889 AnyEvent::detect
748 Returns $AnyEvent::MODEL, forcing autodetection of the event model 890 Returns $AnyEvent::MODEL, forcing autodetection of the event model
749 if necessary. You should only call this function right before you 891 if necessary. You should only call this function right before you
750 would have created an AnyEvent watcher anyway, that is, as late as 892 would have created an AnyEvent watcher anyway, that is, as late as
751 possible at runtime. 893 possible at runtime, and not e.g. while initialising of your module.
894
895 If you need to do some initialisation before AnyEvent watchers are
896 created, use "post_detect".
752 897
753 $guard = AnyEvent::post_detect { BLOCK } 898 $guard = AnyEvent::post_detect { BLOCK }
754 Arranges for the code block to be executed as soon as the event 899 Arranges for the code block to be executed as soon as the event
755 model is autodetected (or immediately if this has already happened). 900 model is autodetected (or immediately if this has already happened).
756 901
902 The block will be executed *after* the actual backend has been
903 detected ($AnyEvent::MODEL is set), but *before* any watchers have
904 been created, so it is possible to e.g. patch @AnyEvent::ISA or do
905 other initialisations - see the sources of AnyEvent::Strict or
906 AnyEvent::AIO to see how this is used.
907
908 The most common usage is to create some global watchers, without
909 forcing event module detection too early, for example, AnyEvent::AIO
910 creates and installs the global IO::AIO watcher in a "post_detect"
911 block to avoid autodetecting the event module at load time.
912
757 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
758 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
759 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;
760 933
761 @AnyEvent::post_detect 934 @AnyEvent::post_detect
762 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
763 before or after loading AnyEvent), then they will called directly 936 before or after loading AnyEvent), then they will called directly
764 after the event loop has been chosen. 937 after the event loop has been chosen.
765 938
766 You should check $AnyEvent::MODEL before adding to this array, 939 You should check $AnyEvent::MODEL before adding to this array,
767 though: if it contains a true value then the event loop has already 940 though: if it is defined then the event loop has already been
768 been detected, and the array will be ignored. 941 detected, and the array will be ignored.
769 942
770 Best use "AnyEvent::post_detect { BLOCK }" instead. 943 Best use "AnyEvent::post_detect { BLOCK }" when your application
944 allows it, as it takes care of these details.
945
946 This variable is mainly useful for modules that can do something
947 useful when AnyEvent is used and thus want to know when it is
948 initialised, but do not need to even load it by default. This array
949 provides the means to hook into AnyEvent passively, without loading
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 }
771 964
772WHAT TO DO IN A MODULE 965WHAT TO DO IN A MODULE
773 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
774 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.
775 968
826 variable somewhere, waiting for it, and sending it when the program 1019 variable somewhere, waiting for it, and sending it when the program
827 should exit cleanly. 1020 should exit cleanly.
828 1021
829OTHER MODULES 1022OTHER MODULES
830 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
831 AnyEvent and can therefore be mixed easily with other AnyEvent modules 1024 AnyEvent as a client and can therefore be mixed easily with other
832 in the same program. Some of the modules come with AnyEvent, some are 1025 AnyEvent modules and other event loops in the same program. Some of the
833 available via CPAN. 1026 modules come as part of AnyEvent, the others are available via CPAN.
834 1027
835 AnyEvent::Util 1028 AnyEvent::Util
836 Contains various utility functions that replace often-used but 1029 Contains various utility functions that replace often-used but
837 blocking functions such as "inet_aton" by event-/callback-based 1030 blocking functions such as "inet_aton" by event-/callback-based
838 versions. 1031 versions.
844 more. 1037 more.
845 1038
846 AnyEvent::Handle 1039 AnyEvent::Handle
847 Provide read and write buffers, manages watchers for reads and 1040 Provide read and write buffers, manages watchers for reads and
848 writes, supports raw and formatted I/O, I/O queued and fully 1041 writes, supports raw and formatted I/O, I/O queued and fully
849 transparent and non-blocking SSL/TLS. 1042 transparent and non-blocking SSL/TLS (via AnyEvent::TLS.
850 1043
851 AnyEvent::DNS 1044 AnyEvent::DNS
852 Provides rich asynchronous DNS resolver capabilities. 1045 Provides rich asynchronous DNS resolver capabilities.
853 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
854 AnyEvent::HTTP 1070 AnyEvent::DBI
855 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,
856 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.
857 1079
858 AnyEvent::HTTPD 1080 AnyEvent::HTTPD
859 Provides a simple web application server framework. 1081 A simple embedded webserver.
860 1082
861 AnyEvent::FastPing 1083 AnyEvent::FastPing
862 The fastest ping in the west. 1084 The fastest ping in the west.
863 1085
864 AnyEvent::DBI
865 Executes DBI requests asynchronously in a proxy process.
866
867 AnyEvent::AIO
868 Truly asynchronous I/O, should be in the toolbox of every event
869 programmer. AnyEvent::AIO transparently fuses IO::AIO and AnyEvent
870 together.
871
872 AnyEvent::BDB
873 Truly asynchronous Berkeley DB access. AnyEvent::BDB transparently
874 fuses BDB and AnyEvent together.
875
876 AnyEvent::GPSD
877 A non-blocking interface to gpsd, a daemon delivering GPS
878 information.
879
880 AnyEvent::IGS
881 A non-blocking interface to the Internet Go Server protocol (used by
882 App::IGS).
883
884 AnyEvent::IRC
885 AnyEvent based IRC client module family (replacing the older
886 Net::IRC3).
887
888 Net::XMPP2
889 AnyEvent based XMPP (Jabber protocol) module family.
890
891 Net::FCP
892 AnyEvent-based implementation of the Freenet Client Protocol,
893 birthplace of AnyEvent.
894
895 Event::ExecFlow
896 High level API for event-based execution flow control.
897
898 Coro 1086 Coro
899 Has special support for AnyEvent via Coro::AnyEvent. 1087 Has special support for AnyEvent via Coro::AnyEvent.
900 1088
901 IO::Lambda 1089SIMPLIFIED AE API
902 The lambda approach to I/O - don't ask, look there. Can use 1090 Starting with version 5.0, AnyEvent officially supports a second, much
903 AnyEvent. 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.
904 1095
905ERROR AND EXCEPTION HANDLING 1096ERROR AND EXCEPTION HANDLING
906 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
907 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
908 "PERL_ANYEVENT_STRICT" environment variable, below) provides strict 1099 "PERL_ANYEVENT_STRICT" environment variable, below) provides strict
936 by "PERL_ANYEVENT_MODEL". 1127 by "PERL_ANYEVENT_MODEL".
937 1128
938 When set to 2 or higher, cause AnyEvent to report to STDERR which 1129 When set to 2 or higher, cause AnyEvent to report to STDERR which
939 event model it chooses. 1130 event model it chooses.
940 1131
1132 When set to 8 or higher, then AnyEvent will report extra information
1133 on which optional modules it loads and how it implements certain
1134 features.
1135
941 "PERL_ANYEVENT_STRICT" 1136 "PERL_ANYEVENT_STRICT"
942 AnyEvent does not do much argument checking by default, as thorough 1137 AnyEvent does not do much argument checking by default, as thorough
943 argument checking is very costly. Setting this variable to a true 1138 argument checking is very costly. Setting this variable to a true
944 value will cause AnyEvent to load "AnyEvent::Strict" and then to 1139 value will cause AnyEvent to load "AnyEvent::Strict" and then to
945 thoroughly check the arguments passed to most method calls. If it 1140 thoroughly check the arguments passed to most method calls. If it
946 finds any problems, it will croak. 1141 finds any problems, it will croak.
947 1142
948 In other words, enables "strict" mode. 1143 In other words, enables "strict" mode.
949 1144
950 Unlike "use strict", it is definitely recommended to keep it off in 1145 Unlike "use strict" (or it's modern cousin, "use common::sense", it
951 production. Keeping "PERL_ANYEVENT_STRICT=1" in your environment 1146 is definitely recommended to keep it off in production. Keeping
1147 "PERL_ANYEVENT_STRICT=1" in your environment while developing
952 while developing programs can be very useful, however. 1148 programs can be very useful, however.
953 1149
954 "PERL_ANYEVENT_MODEL" 1150 "PERL_ANYEVENT_MODEL"
955 This can be used to specify the event model to be used by AnyEvent, 1151 This can be used to specify the event model to be used by AnyEvent,
956 before auto detection and -probing kicks in. It must be a string 1152 before auto detection and -probing kicks in. It must be a string
957 consisting entirely of ASCII letters. The string "AnyEvent::Impl::" 1153 consisting entirely of ASCII letters. The string "AnyEvent::Impl::"
998 EDNS0 in its DNS requests. 1194 EDNS0 in its DNS requests.
999 1195
1000 "PERL_ANYEVENT_MAX_FORKS" 1196 "PERL_ANYEVENT_MAX_FORKS"
1001 The maximum number of child processes that 1197 The maximum number of child processes that
1002 "AnyEvent::Util::fork_call" will create in parallel. 1198 "AnyEvent::Util::fork_call" will create in parallel.
1199
1200 "PERL_ANYEVENT_MAX_OUTSTANDING_DNS"
1201 The default value for the "max_outstanding" parameter for the
1202 default DNS resolver - this is the maximum number of parallel DNS
1203 requests that are sent to the DNS server.
1204
1205 "PERL_ANYEVENT_RESOLV_CONF"
1206 The file to use instead of /etc/resolv.conf (or OS-specific
1207 configuration) in the default resolver. When set to the empty
1208 string, no default config will be used.
1209
1210 "PERL_ANYEVENT_CA_FILE", "PERL_ANYEVENT_CA_PATH".
1211 When neither "ca_file" nor "ca_path" was specified during
1212 AnyEvent::TLS context creation, and either of these environment
1213 variables exist, they will be used to specify CA certificate
1214 locations instead of a system-dependent default.
1215
1216 "PERL_ANYEVENT_AVOID_GUARD" and "PERL_ANYEVENT_AVOID_ASYNC_INTERRUPT"
1217 When these are set to 1, then the respective modules are not loaded.
1218 Mostly good for testing AnyEvent itself.
1003 1219
1004SUPPLYING YOUR OWN EVENT MODEL INTERFACE 1220SUPPLYING YOUR OWN EVENT MODEL INTERFACE
1005 This is an advanced topic that you do not normally need to use AnyEvent 1221 This is an advanced topic that you do not normally need to use AnyEvent
1006 in a module. This section is only of use to event loop authors who want 1222 in a module. This section is only of use to event loop authors who want
1007 to provide AnyEvent compatibility. 1223 to provide AnyEvent compatibility.
1062 warn "read: $input\n"; # output what has been read 1278 warn "read: $input\n"; # output what has been read
1063 $cv->send if $input =~ /^q/i; # quit program if /^q/i 1279 $cv->send if $input =~ /^q/i; # quit program if /^q/i
1064 }, 1280 },
1065 ); 1281 );
1066 1282
1067 my $time_watcher; # can only be used once
1068
1069 sub new_timer {
1070 $timer = AnyEvent->timer (after => 1, cb => sub { 1283 my $time_watcher = AnyEvent->timer (after => 1, interval => 1, cb => sub {
1071 warn "timeout\n"; # print 'timeout' about every second 1284 warn "timeout\n"; # print 'timeout' at most every second
1072 &new_timer; # and restart the time
1073 });
1074 } 1285 });
1075
1076 new_timer; # create first timer
1077 1286
1078 $cv->recv; # wait until user enters /^q/i 1287 $cv->recv; # wait until user enters /^q/i
1079 1288
1080REAL-WORLD EXAMPLE 1289REAL-WORLD EXAMPLE
1081 Consider the Net::FCP module. It features (among others) the following 1290 Consider the Net::FCP module. It features (among others) the following
1153 1362
1154 The actual code goes further and collects all errors ("die"s, 1363 The actual code goes further and collects all errors ("die"s,
1155 exceptions) that occurred during request processing. The "result" method 1364 exceptions) that occurred during request processing. The "result" method
1156 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
1157 object) and just throws the exception, which means connection errors and 1366 object) and just throws the exception, which means connection errors and
1158 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,
1159 not in a random callback. 1368 not in a random callback.
1160 1369
1161 All of this enables the following usage styles: 1370 All of this enables the following usage styles:
1162 1371
1163 1. Blocking: 1372 1. Blocking:
1208 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
1209 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,
1210 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.
1211 1420
1212 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
1213 distribution. 1422 distribution. It uses the AE interface, which makes a real difference
1423 for the EV and Perl backends only.
1214 1424
1215 Explanation of the columns 1425 Explanation of the columns
1216 *watcher* is the number of event watchers created/destroyed. Since 1426 *watcher* is the number of event watchers created/destroyed. Since
1217 different event models feature vastly different performances, each event 1427 different event models feature vastly different performances, each event
1218 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
1237 *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
1238 single watcher. 1448 single watcher.
1239 1449
1240 Results 1450 Results
1241 name watchers bytes create invoke destroy comment 1451 name watchers bytes create invoke destroy comment
1242 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
1243 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
1244 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
1245 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
1246 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
1247 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
1248 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
1249 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
1250 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
1251 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
1252 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
1253 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
1254 1464
1255 Discussion 1465 Discussion
1256 The benchmark does *not* measure scalability of the event loop very 1466 The benchmark does *not* measure scalability of the event loop very
1257 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)
1258 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
1269 benchmark machine, handling an event takes roughly 1600 CPU cycles with 1479 benchmark machine, handling an event takes roughly 1600 CPU cycles with
1270 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
1271 CPU cycles with POE. 1481 CPU cycles with POE.
1272 1482
1273 "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
1274 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
1275 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).
1276 natively.
1277 1488
1278 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
1279 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
1280 perl interpreter and the backend itself). Nevertheless this shows that 1491 perl interpreter and the backend itself). Nevertheless this shows that
1281 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
1351 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
1352 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
1353 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.
1354 1565
1355 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
1356 distribution. 1567 distribution. It uses the AE interface, which makes a real difference
1568 for the EV and Perl backends only.
1357 1569
1358 Explanation of the columns 1570 Explanation of the columns
1359 *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"
1360 (as each server has a read and write socket end). 1572 (as each server has a read and write socket end).
1361 1573
1367 forwarding it to another server. This includes deleting the old timeout 1579 forwarding it to another server. This includes deleting the old timeout
1368 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.
1369 1581
1370 Results 1582 Results
1371 name sockets create request 1583 name sockets create request
1372 EV 20000 69.01 11.16 1584 EV 20000 62.66 7.99
1373 Perl 20000 73.32 35.87 1585 Perl 20000 68.32 32.64
1374 IOAsync 20000 157.00 98.14 epoll 1586 IOAsync 20000 174.06 101.15 epoll
1375 IOAsync 20000 159.31 616.06 poll 1587 IOAsync 20000 174.67 610.84 poll
1376 Event 20000 212.62 257.32 1588 Event 20000 202.69 242.91
1377 Glib 20000 651.16 1896.30 1589 Glib 20000 557.01 1689.52
1378 POE 20000 349.67 12317.24 uses POE::Loop::Event 1590 POE 20000 341.54 12086.32 uses POE::Loop::Event
1379 1591
1380 Discussion 1592 Discussion
1381 This benchmark *does* measure scalability and overall performance of the 1593 This benchmark *does* measure scalability and overall performance of the
1382 particular event loop. 1594 particular event loop.
1383 1595
1496 As you can see, the AnyEvent + EV combination even beats the 1708 As you can see, the AnyEvent + EV combination even beats the
1497 hand-optimised "raw sockets benchmark", while AnyEvent + its pure perl 1709 hand-optimised "raw sockets benchmark", while AnyEvent + its pure perl
1498 backend easily beats IO::Lambda and POE. 1710 backend easily beats IO::Lambda and POE.
1499 1711
1500 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
1501 slow :) AnyEvent::Handle abstraction beats both POE and IO::Lambda by a 1713 slow :) AnyEvent::Handle abstraction beats both POE and IO::Lambda
1502 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
1503 in a non-blocking way. 1715 it does all of DNS, tcp-connect and socket I/O in a non-blocking way.
1504 1716
1505 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
1506 eg/ae2.pl in the AnyEvent distribution, the remaining benchmarks are 1718 eg/ae2.pl in the AnyEvent distribution, the remaining benchmarks are
1507 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.
1508 1720
1509SIGNALS 1721SIGNALS
1510 AnyEvent currently installs handlers for these signals: 1722 AnyEvent currently installs handlers for these signals:
1511 1723
1512 SIGCHLD 1724 SIGCHLD
1513 A handler for "SIGCHLD" is installed by AnyEvent's child watcher 1725 A handler for "SIGCHLD" is installed by AnyEvent's child watcher
1514 emulation for event loops that do not support them natively. Also, 1726 emulation for event loops that do not support them natively. Also,
1515 some event loops install a similar handler. 1727 some event loops install a similar handler.
1516 1728
1517 If, when AnyEvent is loaded, SIGCHLD is set to IGNORE, then AnyEvent 1729 Additionally, when AnyEvent is loaded and SIGCHLD is set to IGNORE,
1518 will reset it to default, to avoid losing child exit statuses. 1730 then AnyEvent will reset it to default, to avoid losing child exit
1731 statuses.
1519 1732
1520 SIGPIPE 1733 SIGPIPE
1521 A no-op handler is installed for "SIGPIPE" when $SIG{PIPE} is 1734 A no-op handler is installed for "SIGPIPE" when $SIG{PIPE} is
1522 "undef" when AnyEvent gets loaded. 1735 "undef" when AnyEvent gets loaded.
1523 1736
1531 it is that this way, the handler will be restored to defaults on 1744 it is that this way, the handler will be restored to defaults on
1532 exec. 1745 exec.
1533 1746
1534 Feel free to install your own handler, or reset it to defaults. 1747 Feel free to install your own handler, or reset it to defaults.
1535 1748
1749RECOMMENDED/OPTIONAL MODULES
1750 One of AnyEvent's main goals is to be 100% Pure-Perl(tm): only perl (and
1751 it's built-in modules) are required to use it.
1752
1753 That does not mean that AnyEvent won't take advantage of some additional
1754 modules if they are installed.
1755
1756 This section explains which additional modules will be used, and how
1757 they affect AnyEvent's operation.
1758
1759 Async::Interrupt
1760 This slightly arcane module is used to implement fast signal
1761 handling: To my knowledge, there is no way to do completely
1762 race-free and quick signal handling in pure perl. To ensure that
1763 signals still get delivered, AnyEvent will start an interval timer
1764 to wake up perl (and catch the signals) with some delay (default is
1765 10 seconds, look for $AnyEvent::MAX_SIGNAL_LATENCY).
1766
1767 If this module is available, then it will be used to implement
1768 signal catching, which means that signals will not be delayed, and
1769 the event loop will not be interrupted regularly, which is more
1770 efficient (and good for battery life on laptops).
1771
1772 This affects not just the pure-perl event loop, but also other event
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.
1779
1780 EV This module isn't really "optional", as it is simply one of the
1781 backend event loops that AnyEvent can use. However, it is simply the
1782 best event loop available in terms of features, speed and stability:
1783 It supports the AnyEvent API optimally, implements all the watcher
1784 types in XS, does automatic timer adjustments even when no monotonic
1785 clock is available, can take avdantage of advanced kernel interfaces
1786 such as "epoll" and "kqueue", and is the fastest backend *by far*.
1787 You can even embed Glib/Gtk2 in it (or vice versa, see EV::Glib and
1788 Glib::EV).
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
1793 Guard
1794 The guard module, when used, will be used to implement
1795 "AnyEvent::Util::guard". This speeds up guards considerably (and
1796 uses a lot less memory), but otherwise doesn't affect guard
1797 operation much. It is purely used for performance.
1798
1799 JSON and JSON::XS
1800 One of these modules is required when you want to read or write JSON
1801 data via AnyEvent::Handle. JSON is also written in pure-perl, but
1802 can take advantage of the ultra-high-speed JSON::XS module when it
1803 is installed.
1804
1805 Net::SSLeay
1806 Implementing TLS/SSL in Perl is certainly interesting, but not very
1807 worthwhile: If this module is installed, then AnyEvent::Handle (with
1808 the help of AnyEvent::TLS), gains the ability to do TLS/SSL.
1809
1810 Time::HiRes
1811 This module is part of perl since release 5.008. It will be used
1812 when the chosen event library does not come with a timing source on
1813 it's own. The pure-perl event loop (AnyEvent::Impl::Perl) will
1814 additionally use it to try to use a monotonic clock for timing
1815 stability.
1816
1536FORK 1817FORK
1537 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
1538 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
1539 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).
1540 1830
1541 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
1542 watcher OR you must not use AnyEvent at all in the child. 1832 watcher OR you must not use AnyEvent at all in the child OR you must do
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.
1543 1843
1544SECURITY CONSIDERATIONS 1844SECURITY CONSIDERATIONS
1545 AnyEvent can be forced to load any event model via 1845 AnyEvent can be forced to load any event model via
1546 $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
1547 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
1578 Event modules: EV, EV::Glib, Glib::EV, Event, Glib::Event, Glib, Tk, 1878 Event modules: EV, EV::Glib, Glib::EV, Event, Glib::Event, Glib, Tk,
1579 Event::Lib, Qt, POE. 1879 Event::Lib, Qt, POE.
1580 1880
1581 Implementations: AnyEvent::Impl::EV, AnyEvent::Impl::Event, 1881 Implementations: AnyEvent::Impl::EV, AnyEvent::Impl::Event,
1582 AnyEvent::Impl::Glib, AnyEvent::Impl::Tk, AnyEvent::Impl::Perl, 1882 AnyEvent::Impl::Glib, AnyEvent::Impl::Tk, AnyEvent::Impl::Perl,
1583 AnyEvent::Impl::EventLib, AnyEvent::Impl::Qt, AnyEvent::Impl::POE. 1883 AnyEvent::Impl::EventLib, AnyEvent::Impl::Qt, AnyEvent::Impl::POE,
1884 AnyEvent::Impl::IOAsync, Anyevent::Impl::Irssi.
1584 1885
1585 Non-blocking file handles, sockets, TCP clients and servers: 1886 Non-blocking file handles, sockets, TCP clients and servers:
1586 AnyEvent::Handle, AnyEvent::Socket. 1887 AnyEvent::Handle, AnyEvent::Socket, AnyEvent::TLS.
1587 1888
1588 Asynchronous DNS: AnyEvent::DNS. 1889 Asynchronous DNS: AnyEvent::DNS.
1589 1890
1590 Coroutine support: Coro, Coro::AnyEvent, Coro::EV, Coro::Event, 1891 Coroutine support: Coro, Coro::AnyEvent, Coro::EV, Coro::Event,
1591 1892
1592 Nontrivial usage examples: Net::FCP, Net::XMPP2, AnyEvent::DNS. 1893 Nontrivial usage examples: AnyEvent::GPSD, AnyEvent::XMPP,
1894 AnyEvent::HTTP.
1593 1895
1594AUTHOR 1896AUTHOR
1595 Marc Lehmann <schmorp@schmorp.de> 1897 Marc Lehmann <schmorp@schmorp.de>
1596 http://home.schmorp.de/ 1898 http://home.schmorp.de/
1597 1899

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines