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

Comparing AnyEvent/lib/AnyEvent.pm (file contents):
Revision 1.56 by root, Thu Apr 24 03:10:03 2008 UTC vs.
Revision 1.102 by root, Sun Apr 27 21:16:26 2008 UTC

1=head1 NAME 1=head1 NAME
2 2
3AnyEvent - provide framework for multiple event loops 3AnyEvent - provide framework for multiple event loops
4 4
5EV, Event, Coro::EV, Coro::Event, Glib, Tk, Perl, Event::Lib, Qt - various supported event loops 5EV, Event, Coro::EV, Coro::Event, Glib, Tk, Perl, Event::Lib, Qt, POE - various supported event loops
6 6
7=head1 SYNOPSIS 7=head1 SYNOPSIS
8 8
9 use AnyEvent; 9 use AnyEvent;
10 10
66 66
67Of course, if you want lots of policy (this can arguably be somewhat 67Of course, if you want lots of policy (this can arguably be somewhat
68useful) and you want to force your users to use the one and only event 68useful) and you want to force your users to use the one and only event
69model, you should I<not> use this module. 69model, you should I<not> use this module.
70 70
71
72=head1 DESCRIPTION 71=head1 DESCRIPTION
73 72
74L<AnyEvent> provides an identical interface to multiple event loops. This 73L<AnyEvent> provides an identical interface to multiple event loops. This
75allows module authors to utilise an event loop without forcing module 74allows module authors to utilise an event loop without forcing module
76users to use the same event loop (as only a single event loop can coexist 75users to use the same event loop (as only a single event loop can coexist
80module. 79module.
81 80
82During the first call of any watcher-creation method, the module tries 81During the first call of any watcher-creation method, the module tries
83to detect the currently loaded event loop by probing whether one of the 82to detect the currently loaded event loop by probing whether one of the
84following modules is already loaded: L<Coro::EV>, L<Coro::Event>, L<EV>, 83following modules is already loaded: L<Coro::EV>, L<Coro::Event>, L<EV>,
85L<Event>, L<Glib>, L<Tk>. The first one found is used. If none are found, 84L<Event>, L<Glib>, L<AnyEvent::Impl::Perl>, L<Tk>, L<Event::Lib>, L<Qt>,
86the module tries to load these modules in the stated order. The first one 85L<POE>. The first one found is used. If none are found, the module tries
86to load these modules (excluding Tk, Event::Lib, Qt and POE as the pure perl
87adaptor should always succeed) in the order given. The first one that can
87that can be successfully loaded will be used. If, after this, still none 88be successfully loaded will be used. If, after this, still none could be
88could be found, AnyEvent will fall back to a pure-perl event loop, which 89found, AnyEvent will fall back to a pure-perl event loop, which is not
89is not very efficient, but should work everywhere. 90very efficient, but should work everywhere.
90 91
91Because AnyEvent first checks for modules that are already loaded, loading 92Because AnyEvent first checks for modules that are already loaded, loading
92an event model explicitly before first using AnyEvent will likely make 93an event model explicitly before first using AnyEvent will likely make
93that model the default. For example: 94that model the default. For example:
94 95
134 135
135Note that C<my $w; $w => combination. This is necessary because in Perl, 136Note that C<my $w; $w => combination. This is necessary because in Perl,
136my variables are only visible after the statement in which they are 137my variables are only visible after the statement in which they are
137declared. 138declared.
138 139
139=head2 IO WATCHERS 140=head2 I/O WATCHERS
140 141
141You can create an I/O watcher by calling the C<< AnyEvent->io >> method 142You can create an I/O watcher by calling the C<< AnyEvent->io >> method
142with the following mandatory key-value pairs as arguments: 143with the following mandatory key-value pairs as arguments:
143 144
144C<fh> the Perl I<file handle> (I<not> file descriptor) to watch for 145C<fh> the Perl I<file handle> (I<not> file descriptor) to watch
145events. C<poll> must be a string that is either C<r> or C<w>, which 146for events. C<poll> must be a string that is either C<r> or C<w>,
146creates a watcher waiting for "r"eadable or "w"ritable events, 147which creates a watcher waiting for "r"eadable or "w"ritable events,
147respectively. C<cb> is the callback to invoke each time the file handle 148respectively. C<cb> is the callback to invoke each time the file handle
148becomes ready. 149becomes ready.
149 150
150As long as the I/O watcher exists it will keep the file descriptor or a 151Although the callback might get passed parameters, their value and
151copy of it alive/open. 152presence is undefined and you cannot rely on them. Portable AnyEvent
153callbacks cannot use arguments passed to I/O watcher callbacks.
152 154
155The I/O watcher might use the underlying file descriptor or a copy of it.
153It is not allowed to close a file handle as long as any watcher is active 156You must not close a file handle as long as any watcher is active on the
154on the underlying file descriptor. 157underlying file descriptor.
155 158
156Some event loops issue spurious readyness notifications, so you should 159Some event loops issue spurious readyness notifications, so you should
157always use non-blocking calls when reading/writing from/to your file 160always use non-blocking calls when reading/writing from/to your file
158handles. 161handles.
159 162
170 173
171You can create a time watcher by calling the C<< AnyEvent->timer >> 174You can create a time watcher by calling the C<< AnyEvent->timer >>
172method with the following mandatory arguments: 175method with the following mandatory arguments:
173 176
174C<after> specifies after how many seconds (fractional values are 177C<after> specifies after how many seconds (fractional values are
175supported) should the timer activate. C<cb> the callback to invoke in that 178supported) the callback should be invoked. C<cb> is the callback to invoke
176case. 179in that case.
180
181Although the callback might get passed parameters, their value and
182presence is undefined and you cannot rely on them. Portable AnyEvent
183callbacks cannot use arguments passed to time watcher callbacks.
177 184
178The timer callback will be invoked at most once: if you want a repeating 185The timer callback will be invoked at most once: if you want a repeating
179timer you have to create a new watcher (this is a limitation by both Tk 186timer you have to create a new watcher (this is a limitation by both Tk
180and Glib). 187and Glib).
181 188
206 213
207There are two ways to handle timers: based on real time (relative, "fire 214There are two ways to handle timers: based on real time (relative, "fire
208in 10 seconds") and based on wallclock time (absolute, "fire at 12 215in 10 seconds") and based on wallclock time (absolute, "fire at 12
209o'clock"). 216o'clock").
210 217
211While most event loops expect timers to specified in a relative way, they use 218While most event loops expect timers to specified in a relative way, they
212absolute time internally. This makes a difference when your clock "jumps", 219use absolute time internally. This makes a difference when your clock
213for example, when ntp decides to set your clock backwards from the wrong 2014-01-01 to 220"jumps", for example, when ntp decides to set your clock backwards from
2142008-01-01, a watcher that you created to fire "after" a second might actually take 221the wrong date of 2014-01-01 to 2008-01-01, a watcher that is supposed to
215six years to finally fire. 222fire "after" a second might actually take six years to finally fire.
216 223
217AnyEvent cannot compensate for this. The only event loop that is conscious 224AnyEvent cannot compensate for this. The only event loop that is conscious
218about these issues is L<EV>, which offers both relative (ev_timer) and 225about these issues is L<EV>, which offers both relative (ev_timer, based
219absolute (ev_periodic) timers. 226on true relative time) and absolute (ev_periodic, based on wallclock time)
227timers.
220 228
221AnyEvent always prefers relative timers, if available, matching the 229AnyEvent always prefers relative timers, if available, matching the
222AnyEvent API. 230AnyEvent API.
223 231
224=head2 SIGNAL WATCHERS 232=head2 SIGNAL WATCHERS
225 233
226You can watch for signals using a signal watcher, C<signal> is the signal 234You can watch for signals using a signal watcher, C<signal> is the signal
227I<name> without any C<SIG> prefix, C<cb> is the Perl callback to 235I<name> without any C<SIG> prefix, C<cb> is the Perl callback to
228be invoked whenever a signal occurs. 236be invoked whenever a signal occurs.
229 237
238Although the callback might get passed parameters, their value and
239presence is undefined and you cannot rely on them. Portable AnyEvent
240callbacks cannot use arguments passed to signal watcher callbacks.
241
230Multiple signals occurances can be clumped together into one callback 242Multiple signal occurances can be clumped together into one callback
231invocation, and callback invocation will be synchronous. synchronous means 243invocation, and callback invocation will be synchronous. synchronous means
232that it might take a while until the signal gets handled by the process, 244that it might take a while until the signal gets handled by the process,
233but it is guarenteed not to interrupt any other callbacks. 245but it is guarenteed not to interrupt any other callbacks.
234 246
235The main advantage of using these watchers is that you can share a signal 247The main advantage of using these watchers is that you can share a signal
248 260
249The child process is specified by the C<pid> argument (if set to C<0>, it 261The child process is specified by the C<pid> argument (if set to C<0>, it
250watches for any child process exit). The watcher will trigger as often 262watches for any child process exit). The watcher will trigger as often
251as status change for the child are received. This works by installing a 263as status change for the child are received. This works by installing a
252signal handler for C<SIGCHLD>. The callback will be called with the pid 264signal handler for C<SIGCHLD>. The callback will be called with the pid
253and exit status (as returned by waitpid). 265and exit status (as returned by waitpid), so unlike other watcher types,
266you I<can> rely on child watcher callback arguments.
254 267
255Example: wait for pid 1333 268There is a slight catch to child watchers, however: you usually start them
269I<after> the child process was created, and this means the process could
270have exited already (and no SIGCHLD will be sent anymore).
271
272Not all event models handle this correctly (POE doesn't), but even for
273event models that I<do> handle this correctly, they usually need to be
274loaded before the process exits (i.e. before you fork in the first place).
275
276This means you cannot create a child watcher as the very first thing in an
277AnyEvent program, you I<have> to create at least one watcher before you
278C<fork> the child (alternatively, you can call C<AnyEvent::detect>).
279
280Example: fork a process and wait for it
281
282 my $done = AnyEvent->condvar;
283
284 AnyEvent::detect; # force event module to be initialised
285
286 my $pid = fork or exit 5;
256 287
257 my $w = AnyEvent->child ( 288 my $w = AnyEvent->child (
258 pid => 1333, 289 pid => $pid,
259 cb => sub { 290 cb => sub {
260 my ($pid, $status) = @_; 291 my ($pid, $status) = @_;
261 warn "pid $pid exited with status $status"; 292 warn "pid $pid exited with status $status";
293 $done->broadcast;
262 }, 294 },
263 ); 295 );
296
297 # do something else, then wait for process exit
298 $done->wait;
264 299
265=head2 CONDITION VARIABLES 300=head2 CONDITION VARIABLES
266 301
267Condition variables can be created by calling the C<< AnyEvent->condvar >> 302Condition variables can be created by calling the C<< AnyEvent->condvar >>
268method without any arguments. 303method without any arguments.
356 AnyEvent::Impl::CoroEV based on Coro::EV, best choice. 391 AnyEvent::Impl::CoroEV based on Coro::EV, best choice.
357 AnyEvent::Impl::CoroEvent based on Coro::Event, second best choice. 392 AnyEvent::Impl::CoroEvent based on Coro::Event, second best choice.
358 AnyEvent::Impl::EV based on EV (an interface to libev, best choice). 393 AnyEvent::Impl::EV based on EV (an interface to libev, best choice).
359 AnyEvent::Impl::Event based on Event, second best choice. 394 AnyEvent::Impl::Event based on Event, second best choice.
360 AnyEvent::Impl::Glib based on Glib, third-best choice. 395 AnyEvent::Impl::Glib based on Glib, third-best choice.
396 AnyEvent::Impl::Perl pure-perl implementation, inefficient but portable.
361 AnyEvent::Impl::Tk based on Tk, very bad choice. 397 AnyEvent::Impl::Tk based on Tk, very bad choice.
362 AnyEvent::Impl::Perl pure-perl implementation, inefficient but portable.
363 AnyEvent::Impl::Qt based on Qt, cannot be autoprobed (see its docs). 398 AnyEvent::Impl::Qt based on Qt, cannot be autoprobed (see its docs).
364 AnyEvent::Impl::EventLib based on Event::Lib, leaks memory and worse. 399 AnyEvent::Impl::EventLib based on Event::Lib, leaks memory and worse.
400 AnyEvent::Impl::POE based on POE, not generic enough for full support.
401
402There is no support for WxWidgets, as WxWidgets has no support for
403watching file handles. However, you can use WxWidgets through the
404POE Adaptor, as POE has a Wx backend that simply polls 20 times per
405second, which was considered to be too horrible to even consider for
406AnyEvent. Likewise, other POE backends can be used by AnyEvent by using
407it's adaptor.
408
409AnyEvent knows about L<Prima> and L<Wx> and will try to use L<POE> when
410autodetecting them.
365 411
366=item AnyEvent::detect 412=item AnyEvent::detect
367 413
368Returns C<$AnyEvent::MODEL>, forcing autodetection of the event model 414Returns C<$AnyEvent::MODEL>, forcing autodetection of the event model
369if necessary. You should only call this function right before you would 415if necessary. You should only call this function right before you would
411 457
412You can chose to use a rather inefficient pure-perl implementation by 458You can chose to use a rather inefficient pure-perl implementation by
413loading the C<AnyEvent::Impl::Perl> module, which gives you similar 459loading the C<AnyEvent::Impl::Perl> module, which gives you similar
414behaviour everywhere, but letting AnyEvent chose is generally better. 460behaviour everywhere, but letting AnyEvent chose is generally better.
415 461
462=head1 OTHER MODULES
463
464The following is a non-exhaustive list of additional modules that use
465AnyEvent and can therefore be mixed easily with other AnyEvent modules
466in the same program. Some of the modules come with AnyEvent, some are
467available via CPAN.
468
469=over 4
470
471=item L<AnyEvent::Util>
472
473Contains various utility functions that replace often-used but blocking
474functions such as C<inet_aton> by event-/callback-based versions.
475
476=item L<AnyEvent::Handle>
477
478Provide read and write buffers and manages watchers for reads and writes.
479
480=item L<AnyEvent::Socket>
481
482Provides a means to do non-blocking connects, accepts etc.
483
484=item L<AnyEvent::HTTPD>
485
486Provides a simple web application server framework.
487
488=item L<AnyEvent::DNS>
489
490Provides asynchronous DNS resolver capabilities, beyond what
491L<AnyEvent::Util> offers.
492
493=item L<AnyEvent::FastPing>
494
495The fastest ping in the west.
496
497=item L<Net::IRC3>
498
499AnyEvent based IRC client module family.
500
501=item L<Net::XMPP2>
502
503AnyEvent based XMPP (Jabber protocol) module family.
504
505=item L<Net::FCP>
506
507AnyEvent-based implementation of the Freenet Client Protocol, birthplace
508of AnyEvent.
509
510=item L<Event::ExecFlow>
511
512High level API for event-based execution flow control.
513
514=item L<Coro>
515
516Has special support for AnyEvent.
517
518=item L<IO::Lambda>
519
520The lambda approach to I/O - don't ask, look there. Can use AnyEvent.
521
522=item L<IO::AIO>
523
524Truly asynchronous I/O, should be in the toolbox of every event
525programmer. Can be trivially made to use AnyEvent.
526
527=item L<BDB>
528
529Truly asynchronous Berkeley DB access. Can be trivially made to use
530AnyEvent.
531
532=back
533
416=cut 534=cut
417 535
418package AnyEvent; 536package AnyEvent;
419 537
420no warnings; 538no warnings;
421use strict; 539use strict;
422 540
423use Carp; 541use Carp;
424 542
425our $VERSION = '3.12'; 543our $VERSION = '3.3';
426our $MODEL; 544our $MODEL;
427 545
428our $AUTOLOAD; 546our $AUTOLOAD;
429our @ISA; 547our @ISA;
430 548
437 [Coro::Event:: => AnyEvent::Impl::CoroEvent::], 555 [Coro::Event:: => AnyEvent::Impl::CoroEvent::],
438 [EV:: => AnyEvent::Impl::EV::], 556 [EV:: => AnyEvent::Impl::EV::],
439 [Event:: => AnyEvent::Impl::Event::], 557 [Event:: => AnyEvent::Impl::Event::],
440 [Glib:: => AnyEvent::Impl::Glib::], 558 [Glib:: => AnyEvent::Impl::Glib::],
441 [Tk:: => AnyEvent::Impl::Tk::], 559 [Tk:: => AnyEvent::Impl::Tk::],
560 [Wx:: => AnyEvent::Impl::POE::],
561 [Prima:: => AnyEvent::Impl::POE::],
442 [AnyEvent::Impl::Perl:: => AnyEvent::Impl::Perl::], 562 [AnyEvent::Impl::Perl:: => AnyEvent::Impl::Perl::],
443); 563 # everything below here will not be autoprobed as the pureperl backend should work everywhere
444my @models_detect = ( 564 [Event::Lib:: => AnyEvent::Impl::EventLib::], # too buggy
445 [Qt:: => AnyEvent::Impl::Qt::], # requires special main program 565 [Qt:: => AnyEvent::Impl::Qt::], # requires special main program
446 [Event::Lib:: => AnyEvent::Impl::EventLib::], # too buggy 566 [POE::Kernel:: => AnyEvent::Impl::POE::], # lasciate ogni speranza
447); 567);
448 568
449our %method = map +($_ => 1), qw(io timer signal child condvar broadcast wait one_event DESTROY); 569our %method = map +($_ => 1), qw(io timer signal child condvar broadcast wait one_event DESTROY);
450 570
451sub detect() { 571sub detect() {
455 if ($ENV{PERL_ANYEVENT_MODEL} =~ /^([a-zA-Z]+)$/) { 575 if ($ENV{PERL_ANYEVENT_MODEL} =~ /^([a-zA-Z]+)$/) {
456 my $model = "AnyEvent::Impl::$1"; 576 my $model = "AnyEvent::Impl::$1";
457 if (eval "require $model") { 577 if (eval "require $model") {
458 $MODEL = $model; 578 $MODEL = $model;
459 warn "AnyEvent: loaded model '$model' (forced by \$PERL_ANYEVENT_MODEL), using it.\n" if $verbose > 1; 579 warn "AnyEvent: loaded model '$model' (forced by \$PERL_ANYEVENT_MODEL), using it.\n" if $verbose > 1;
580 } else {
581 warn "AnyEvent: unable to load model '$model' (from \$PERL_ANYEVENT_MODEL):\n$@" if $verbose;
460 } 582 }
461 } 583 }
462 584
463 # check for already loaded models 585 # check for already loaded models
464 unless ($MODEL) { 586 unless ($MODEL) {
465 for (@REGISTRY, @models, @models_detect) { 587 for (@REGISTRY, @models) {
466 my ($package, $model) = @$_; 588 my ($package, $model) = @$_;
467 if (${"$package\::VERSION"} > 0) { 589 if (${"$package\::VERSION"} > 0) {
468 if (eval "require $model") { 590 if (eval "require $model") {
469 $MODEL = $model; 591 $MODEL = $model;
470 warn "AnyEvent: autodetected model '$model', using it.\n" if $verbose > 1; 592 warn "AnyEvent: autodetected model '$model', using it.\n" if $verbose > 1;
657 779
658=over 4 780=over 4
659 781
660=item C<PERL_ANYEVENT_VERBOSE> 782=item C<PERL_ANYEVENT_VERBOSE>
661 783
784By default, AnyEvent will be completely silent except in fatal
785conditions. You can set this environment variable to make AnyEvent more
786talkative.
787
788When set to C<1> or higher, causes AnyEvent to warn about unexpected
789conditions, such as not being able to load the event model specified by
790C<PERL_ANYEVENT_MODEL>.
791
662When set to C<2> or higher, cause AnyEvent to report to STDERR which event 792When set to C<2> or higher, cause AnyEvent to report to STDERR which event
663model it chooses. 793model it chooses.
664 794
665=item C<PERL_ANYEVENT_MODEL> 795=item C<PERL_ANYEVENT_MODEL>
666 796
680 810
681=back 811=back
682 812
683=head1 EXAMPLE PROGRAM 813=head1 EXAMPLE PROGRAM
684 814
685The following program uses an IO watcher to read data from STDIN, a timer 815The following program uses an I/O watcher to read data from STDIN, a timer
686to display a message once per second, and a condition variable to quit the 816to display a message once per second, and a condition variable to quit the
687program when the user enters quit: 817program when the user enters quit:
688 818
689 use AnyEvent; 819 use AnyEvent;
690 820
834 $quit->broadcast; 964 $quit->broadcast;
835 }); 965 });
836 966
837 $quit->wait; 967 $quit->wait;
838 968
969
970=head1 BENCHMARKS
971
972To give you an idea of the performance and overheads that AnyEvent adds
973over the event loops themselves and to give you an impression of the speed
974of various event loops I prepared some benchmarks.
975
976=head2 BENCHMARKING ANYEVENT OVERHEAD
977
978Here is a benchmark of various supported event models used natively and
979through anyevent. The benchmark creates a lot of timers (with a zero
980timeout) and I/O watchers (watching STDOUT, a pty, to become writable,
981which it is), lets them fire exactly once and destroys them again.
982
983Source code for this benchmark is found as F<eg/bench> in the AnyEvent
984distribution.
985
986=head3 Explanation of the columns
987
988I<watcher> is the number of event watchers created/destroyed. Since
989different event models feature vastly different performances, each event
990loop was given a number of watchers so that overall runtime is acceptable
991and similar between tested event loop (and keep them from crashing): Glib
992would probably take thousands of years if asked to process the same number
993of watchers as EV in this benchmark.
994
995I<bytes> is the number of bytes (as measured by the resident set size,
996RSS) consumed by each watcher. This method of measuring captures both C
997and Perl-based overheads.
998
999I<create> is the time, in microseconds (millionths of seconds), that it
1000takes to create a single watcher. The callback is a closure shared between
1001all watchers, to avoid adding memory overhead. That means closure creation
1002and memory usage is not included in the figures.
1003
1004I<invoke> is the time, in microseconds, used to invoke a simple
1005callback. The callback simply counts down a Perl variable and after it was
1006invoked "watcher" times, it would C<< ->broadcast >> a condvar once to
1007signal the end of this phase.
1008
1009I<destroy> is the time, in microseconds, that it takes to destroy a single
1010watcher.
1011
1012=head3 Results
1013
1014 name watchers bytes create invoke destroy comment
1015 EV/EV 400000 244 0.56 0.46 0.31 EV native interface
1016 EV/Any 100000 244 2.50 0.46 0.29 EV + AnyEvent watchers
1017 CoroEV/Any 100000 244 2.49 0.44 0.29 coroutines + Coro::Signal
1018 Perl/Any 100000 513 4.92 0.87 1.12 pure perl implementation
1019 Event/Event 16000 516 31.88 31.30 0.85 Event native interface
1020 Event/Any 16000 590 35.75 31.42 1.08 Event + AnyEvent watchers
1021 Glib/Any 16000 1357 98.22 12.41 54.00 quadratic behaviour
1022 Tk/Any 2000 1860 26.97 67.98 14.00 SEGV with >> 2000 watchers
1023 POE/Event 2000 6644 108.64 736.02 14.73 via POE::Loop::Event
1024 POE/Select 2000 6343 94.13 809.12 565.96 via POE::Loop::Select
1025
1026=head3 Discussion
1027
1028The benchmark does I<not> measure scalability of the event loop very
1029well. For example, a select-based event loop (such as the pure perl one)
1030can never compete with an event loop that uses epoll when the number of
1031file descriptors grows high. In this benchmark, all events become ready at
1032the same time, so select/poll-based implementations get an unnatural speed
1033boost.
1034
1035Also, note that the number of watchers usually has a nonlinear effect on
1036overall speed, that is, creating twice as many watchers doesn't take twice
1037the time - usually it takes longer. This puts event loops tested with a
1038higher number of watchers at a disadvantage.
1039
1040To put the range of results into perspective, consider that on the
1041benchmark machine, handling an event takes roughly 1600 CPU cycles with
1042EV, 3100 CPU cycles with AnyEvent's pure perl loop and almost 3000000 CPU
1043cycles with POE.
1044
1045C<EV> is the sole leader regarding speed and memory use, which are both
1046maximal/minimal, respectively. Even when going through AnyEvent, it uses
1047far less memory than any other event loop and is still faster than Event
1048natively.
1049
1050The pure perl implementation is hit in a few sweet spots (both the
1051constant timeout and the use of a single fd hit optimisations in the perl
1052interpreter and the backend itself). Nevertheless this shows that it
1053adds very little overhead in itself. Like any select-based backend its
1054performance becomes really bad with lots of file descriptors (and few of
1055them active), of course, but this was not subject of this benchmark.
1056
1057The C<Event> module has a relatively high setup and callback invocation
1058cost, but overall scores in on the third place.
1059
1060C<Glib>'s memory usage is quite a bit higher, but it features a
1061faster callback invocation and overall ends up in the same class as
1062C<Event>. However, Glib scales extremely badly, doubling the number of
1063watchers increases the processing time by more than a factor of four,
1064making it completely unusable when using larger numbers of watchers
1065(note that only a single file descriptor was used in the benchmark, so
1066inefficiencies of C<poll> do not account for this).
1067
1068The C<Tk> adaptor works relatively well. The fact that it crashes with
1069more than 2000 watchers is a big setback, however, as correctness takes
1070precedence over speed. Nevertheless, its performance is surprising, as the
1071file descriptor is dup()ed for each watcher. This shows that the dup()
1072employed by some adaptors is not a big performance issue (it does incur a
1073hidden memory cost inside the kernel which is not reflected in the figures
1074above).
1075
1076C<POE>, regardless of underlying event loop (whether using its pure
1077perl select-based backend or the Event module, the POE-EV backend
1078couldn't be tested because it wasn't working) shows abysmal performance
1079and memory usage: Watchers use almost 30 times as much memory as
1080EV watchers, and 10 times as much memory as Event (the high memory
1081requirements are caused by requiring a session for each watcher). Watcher
1082invocation speed is almost 900 times slower than with AnyEvent's pure perl
1083implementation. The design of the POE adaptor class in AnyEvent can not
1084really account for this, as session creation overhead is small compared
1085to execution of the state machine, which is coded pretty optimally within
1086L<AnyEvent::Impl::POE>. POE simply seems to be abysmally slow.
1087
1088=head3 Summary
1089
1090=over 4
1091
1092=item * Using EV through AnyEvent is faster than any other event loop
1093(even when used without AnyEvent), but most event loops have acceptable
1094performance with or without AnyEvent.
1095
1096=item * The overhead AnyEvent adds is usually much smaller than the overhead of
1097the actual event loop, only with extremely fast event loops such as EV
1098adds AnyEvent significant overhead.
1099
1100=item * You should avoid POE like the plague if you want performance or
1101reasonable memory usage.
1102
1103=back
1104
1105=head2 BENCHMARKING THE LARGE SERVER CASE
1106
1107This benchmark atcually benchmarks the event loop itself. It works by
1108creating a number of "servers": each server consists of a socketpair, a
1109timeout watcher that gets reset on activity (but never fires), and an I/O
1110watcher waiting for input on one side of the socket. Each time the socket
1111watcher reads a byte it will write that byte to a random other "server".
1112
1113The effect is that there will be a lot of I/O watchers, only part of which
1114are active at any one point (so there is a constant number of active
1115fds for each loop iterstaion, but which fds these are is random). The
1116timeout is reset each time something is read because that reflects how
1117most timeouts work (and puts extra pressure on the event loops).
1118
1119In this benchmark, we use 10000 socketpairs (20000 sockets), of which 100
1120(1%) are active. This mirrors the activity of large servers with many
1121connections, most of which are idle at any one point in time.
1122
1123Source code for this benchmark is found as F<eg/bench2> in the AnyEvent
1124distribution.
1125
1126=head3 Explanation of the columns
1127
1128I<sockets> is the number of sockets, and twice the number of "servers" (as
1129each server has a read and write socket end).
1130
1131I<create> is the time it takes to create a socketpair (which is
1132nontrivial) and two watchers: an I/O watcher and a timeout watcher.
1133
1134I<request>, the most important value, is the time it takes to handle a
1135single "request", that is, reading the token from the pipe and forwarding
1136it to another server. This includes deleting the old timeout and creating
1137a new one that moves the timeout into the future.
1138
1139=head3 Results
1140
1141 name sockets create request
1142 EV 20000 69.01 11.16
1143 Perl 20000 73.32 35.87
1144 Event 20000 212.62 257.32
1145 Glib 20000 651.16 1896.30
1146 POE 20000 349.67 12317.24 uses POE::Loop::Event
1147
1148=head3 Discussion
1149
1150This benchmark I<does> measure scalability and overall performance of the
1151particular event loop.
1152
1153EV is again fastest. Since it is using epoll on my system, the setup time
1154is relatively high, though.
1155
1156Perl surprisingly comes second. It is much faster than the C-based event
1157loops Event and Glib.
1158
1159Event suffers from high setup time as well (look at its code and you will
1160understand why). Callback invocation also has a high overhead compared to
1161the C<< $_->() for .. >>-style loop that the Perl event loop uses. Event
1162uses select or poll in basically all documented configurations.
1163
1164Glib is hit hard by its quadratic behaviour w.r.t. many watchers. It
1165clearly fails to perform with many filehandles or in busy servers.
1166
1167POE is still completely out of the picture, taking over 1000 times as long
1168as EV, and over 100 times as long as the Perl implementation, even though
1169it uses a C-based event loop in this case.
1170
1171=head3 Summary
1172
1173=over 4
1174
1175=item * The pure perl implementation performs extremely well, considering
1176that it uses select.
1177
1178=item * Avoid Glib or POE in large projects where performance matters.
1179
1180=back
1181
1182=head2 BENCHMARKING SMALL SERVERS
1183
1184While event loops should scale (and select-based ones do not...) even to
1185large servers, most programs we (or I :) actually write have only a few
1186I/O watchers.
1187
1188In this benchmark, I use the same benchmark program as in the large server
1189case, but it uses only eight "servers", of which three are active at any
1190one time. This should reflect performance for a small server relatively
1191well.
1192
1193The columns are identical to the previous table.
1194
1195=head3 Results
1196
1197 name sockets create request
1198 EV 16 20.00 6.54
1199 Perl 16 25.75 12.62
1200 Event 16 81.27 35.86
1201 Glib 16 32.63 15.48
1202 POE 16 261.87 276.28 uses POE::Loop::Event
1203
1204=head3 Discussion
1205
1206The benchmark tries to test the performance of a typical small
1207server. While knowing how various event loops perform is interesting, keep
1208in mind that their overhead in this case is usually not as important, due
1209to the small absolute number of watchers (that is, you need efficiency and
1210speed most when you have lots of watchers, not when you only have a few of
1211them).
1212
1213EV is again fastest.
1214
1215Perl again comes second. It is noticably faster than the C-based event
1216loops Event and Glib, although the difference is too small to really
1217matter.
1218
1219POE also performs much better in this case, but is is still far behind the
1220others.
1221
1222=head3 Summary
1223
1224=over 4
1225
1226=item * C-based event loops perform very well with small number of
1227watchers, as the management overhead dominates.
1228
1229=back
1230
1231
839=head1 FORK 1232=head1 FORK
840 1233
841Most event libraries are not fork-safe. The ones who are usually are 1234Most event libraries are not fork-safe. The ones who are usually are
842because they are so inefficient. Only L<EV> is fully fork-aware. 1235because they are so inefficient. Only L<EV> is fully fork-aware.
843 1236
844If you have to fork, you must either do so I<before> creating your first 1237If you have to fork, you must either do so I<before> creating your first
845watcher OR you must not use AnyEvent at all in the child. 1238watcher OR you must not use AnyEvent at all in the child.
1239
846 1240
847=head1 SECURITY CONSIDERATIONS 1241=head1 SECURITY CONSIDERATIONS
848 1242
849AnyEvent can be forced to load any event model via 1243AnyEvent can be forced to load any event model via
850$ENV{PERL_ANYEVENT_MODEL}. While this cannot (to my knowledge) be used to 1244$ENV{PERL_ANYEVENT_MODEL}. While this cannot (to my knowledge) be used to
858 1252
859 BEGIN { delete $ENV{PERL_ANYEVENT_MODEL} } 1253 BEGIN { delete $ENV{PERL_ANYEVENT_MODEL} }
860 1254
861 use AnyEvent; 1255 use AnyEvent;
862 1256
1257
863=head1 SEE ALSO 1258=head1 SEE ALSO
864 1259
865Event modules: L<Coro::EV>, L<EV>, L<EV::Glib>, L<Glib::EV>, 1260Event modules: L<Coro::EV>, L<EV>, L<EV::Glib>, L<Glib::EV>,
866L<Coro::Event>, L<Event>, L<Glib::Event>, L<Glib>, L<Coro>, L<Tk>, 1261L<Coro::Event>, L<Event>, L<Glib::Event>, L<Glib>, L<Coro>, L<Tk>,
867L<Event::Lib>, L<Qt>. 1262L<Event::Lib>, L<Qt>, L<POE>.
868 1263
869Implementations: L<AnyEvent::Impl::CoroEV>, L<AnyEvent::Impl::EV>, 1264Implementations: L<AnyEvent::Impl::CoroEV>, L<AnyEvent::Impl::EV>,
870L<AnyEvent::Impl::CoroEvent>, L<AnyEvent::Impl::Event>, L<AnyEvent::Impl::Glib>, 1265L<AnyEvent::Impl::CoroEvent>, L<AnyEvent::Impl::Event>, L<AnyEvent::Impl::Glib>,
871L<AnyEvent::Impl::Tk>, L<AnyEvent::Impl::Perl>, L<AnyEvent::Impl::EventLib>, 1266L<AnyEvent::Impl::Tk>, L<AnyEvent::Impl::Perl>, L<AnyEvent::Impl::EventLib>,
872L<AnyEvent::Impl::Qt>. 1267L<AnyEvent::Impl::Qt>, L<AnyEvent::Impl::POE>.
873 1268
874Nontrivial usage examples: L<Net::FCP>, L<Net::XMPP2>. 1269Nontrivial usage examples: L<Net::FCP>, L<Net::XMPP2>.
1270
875 1271
876=head1 AUTHOR 1272=head1 AUTHOR
877 1273
878 Marc Lehmann <schmorp@schmorp.de> 1274 Marc Lehmann <schmorp@schmorp.de>
879 http://home.schmorp.de/ 1275 http://home.schmorp.de/

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines