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.64 by root, Fri Apr 25 06:54:08 2008 UTC vs.
Revision 1.83 by root, Fri Apr 25 13:39:08 2008 UTC

… …
80module. 80module.
81 81
82During the first call of any watcher-creation method, the module tries 82During the first call of any watcher-creation method, the module tries
83to detect the currently loaded event loop by probing whether one of the 83to 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>, 84following modules is already loaded: L<Coro::EV>, L<Coro::Event>, L<EV>,
85L<Event>, L<Glib>, L<Tk>, L<AnyEvent::Impl::Perl>, L<Event::Lib>, L<Qt>, 85L<Event>, L<Glib>, L<AnyEvent::Impl::Perl>, L<Tk>, L<Event::Lib>, L<Qt>,
86L<POE>. The first one found is used. If none are found, the module tries 86L<POE>. The first one found is used. If none are found, the module tries
87to load these modules (excluding Event::Lib, Qt and POE as the pure perl 87to load these modules (excluding Tk, Event::Lib, Qt and POE as the pure perl
88adaptor should always succeed) in the order given. The first one that can 88adaptor should always succeed) in the order given. The first one that can
89be successfully loaded will be used. If, after this, still none could be 89be successfully loaded will be used. If, after this, still none could be
90found, AnyEvent will fall back to a pure-perl event loop, which is not 90found, AnyEvent will fall back to a pure-perl event loop, which is not
91very efficient, but should work everywhere. 91very efficient, but should work everywhere.
92 92
… …
136 136
137Note that C<my $w; $w => combination. This is necessary because in Perl, 137Note that C<my $w; $w => combination. This is necessary because in Perl,
138my variables are only visible after the statement in which they are 138my variables are only visible after the statement in which they are
139declared. 139declared.
140 140
141=head2 IO WATCHERS 141=head2 I/O WATCHERS
142 142
143You can create an I/O watcher by calling the C<< AnyEvent->io >> method 143You can create an I/O watcher by calling the C<< AnyEvent->io >> method
144with the following mandatory key-value pairs as arguments: 144with the following mandatory key-value pairs as arguments:
145 145
146C<fh> the Perl I<file handle> (I<not> file descriptor) to watch for 146C<fh> the Perl I<file handle> (I<not> file descriptor) to watch for
147events. C<poll> must be a string that is either C<r> or C<w>, which 147events. C<poll> must be a string that is either C<r> or C<w>, which
148creates a watcher waiting for "r"eadable or "w"ritable events, 148creates a watcher waiting for "r"eadable or "w"ritable events,
149respectively. C<cb> is the callback to invoke each time the file handle 149respectively. C<cb> is the callback to invoke each time the file handle
150becomes ready. 150becomes ready.
151 151
152As long as the I/O watcher exists it will keep the file descriptor or a 152The I/O watcher might use the underlying file descriptor or a copy of it.
153copy of it alive/open.
154
155It is not allowed to close a file handle as long as any watcher is active 153It is not allowed to close a file handle as long as any watcher is active
156on the underlying file descriptor. 154on the underlying file descriptor.
157 155
158Some event loops issue spurious readyness notifications, so you should 156Some event loops issue spurious readyness notifications, so you should
159always use non-blocking calls when reading/writing from/to your file 157always use non-blocking calls when reading/writing from/to your file
… …
253watches for any child process exit). The watcher will trigger as often 251watches for any child process exit). The watcher will trigger as often
254as status change for the child are received. This works by installing a 252as status change for the child are received. This works by installing a
255signal handler for C<SIGCHLD>. The callback will be called with the pid 253signal handler for C<SIGCHLD>. The callback will be called with the pid
256and exit status (as returned by waitpid). 254and exit status (as returned by waitpid).
257 255
258Example: wait for pid 1333 256There is a slight catch to child watchers, however: you usually start them
257I<after> the child process was created, and this means the process could
258have exited already (and no SIGCHLD will be sent anymore).
259
260Not all event models handle this correctly (POE doesn't), but even for
261event models that I<do> handle this correctly, they usually need to be
262loaded before the process exits (i.e. before you fork in the first place).
263
264This means you cannot create a child watcher as the very first thing in an
265AnyEvent program, you I<have> to create at least one watcher before you
266C<fork> the child (alternatively, you can call C<AnyEvent::detect>).
267
268Example: fork a process and wait for it
269
270 my $done = AnyEvent->condvar;
271
272 AnyEvent::detect; # force event module to be initialised
273
274 my $pid = fork or exit 5;
259 275
260 my $w = AnyEvent->child ( 276 my $w = AnyEvent->child (
261 pid => 1333, 277 pid => $pid,
262 cb => sub { 278 cb => sub {
263 my ($pid, $status) = @_; 279 my ($pid, $status) = @_;
264 warn "pid $pid exited with status $status"; 280 warn "pid $pid exited with status $status";
281 $done->broadcast;
265 }, 282 },
266 ); 283 );
284
285 # do something else, then wait for process exit
286 $done->wait;
267 287
268=head2 CONDITION VARIABLES 288=head2 CONDITION VARIABLES
269 289
270Condition variables can be created by calling the C<< AnyEvent->condvar >> 290Condition variables can be created by calling the C<< AnyEvent->condvar >>
271method without any arguments. 291method without any arguments.
… …
359 AnyEvent::Impl::CoroEV based on Coro::EV, best choice. 379 AnyEvent::Impl::CoroEV based on Coro::EV, best choice.
360 AnyEvent::Impl::CoroEvent based on Coro::Event, second best choice. 380 AnyEvent::Impl::CoroEvent based on Coro::Event, second best choice.
361 AnyEvent::Impl::EV based on EV (an interface to libev, best choice). 381 AnyEvent::Impl::EV based on EV (an interface to libev, best choice).
362 AnyEvent::Impl::Event based on Event, second best choice. 382 AnyEvent::Impl::Event based on Event, second best choice.
363 AnyEvent::Impl::Glib based on Glib, third-best choice. 383 AnyEvent::Impl::Glib based on Glib, third-best choice.
384 AnyEvent::Impl::Perl pure-perl implementation, inefficient but portable.
364 AnyEvent::Impl::Tk based on Tk, very bad choice. 385 AnyEvent::Impl::Tk based on Tk, very bad choice.
365 AnyEvent::Impl::Perl pure-perl implementation, inefficient but portable.
366 AnyEvent::Impl::Qt based on Qt, cannot be autoprobed (see its docs). 386 AnyEvent::Impl::Qt based on Qt, cannot be autoprobed (see its docs).
367 AnyEvent::Impl::EventLib based on Event::Lib, leaks memory and worse. 387 AnyEvent::Impl::EventLib based on Event::Lib, leaks memory and worse.
368 AnyEvent::Impl::POE based on POE, not generic enough for full support. 388 AnyEvent::Impl::POE based on POE, not generic enough for full support.
369 389
370There is no support for WxWidgets, as WxWidgets has no support for 390There is no support for WxWidgets, as WxWidgets has no support for
… …
706 726
707=back 727=back
708 728
709=head1 EXAMPLE PROGRAM 729=head1 EXAMPLE PROGRAM
710 730
711The following program uses an IO watcher to read data from STDIN, a timer 731The following program uses an I/O watcher to read data from STDIN, a timer
712to display a message once per second, and a condition variable to quit the 732to display a message once per second, and a condition variable to quit the
713program when the user enters quit: 733program when the user enters quit:
714 734
715 use AnyEvent; 735 use AnyEvent;
716 736
… …
863 $quit->wait; 883 $quit->wait;
864 884
865 885
866=head1 BENCHMARK 886=head1 BENCHMARK
867 887
868To give you an idea of the performance an doverheads that AnyEvent adds 888To give you an idea of the performance and overheads that AnyEvent adds
869over the backends, here is a benchmark of various supported backends. The 889over the event loops themselves (and to give you an impression of the
870benchmark creates a lot of timers (with zero timeout) and io events 890speed of various event loops), here is a benchmark of various supported
871(watching STDOUT, a pty, to become writable). 891event models natively and with anyevent. The benchmark creates a lot of
892timers (with a zero timeout) and I/O watchers (watching STDOUT, a pty, to
893become writable, which it is), lets them fire exactly once and destroys
894them again.
872 895
873Explanation of the fields: 896Rewriting the benchmark to use many different sockets instead of using
897the same filehandle for all I/O watchers results in a much longer runtime
898(socket creation is expensive), but qualitatively the same figures, so it
899was not used.
874 900
901=head2 Explanation of the columns
902
875I<watcher> is the number of event watchers created/destroyed. Sicne 903I<watcher> is the number of event watchers created/destroyed. Since
876different event models have vastly different performance each backend was 904different event models feature vastly different performances, each event
877handed a number of watchers so that overall runtime is acceptable and 905loop was given a number of watchers so that overall runtime is acceptable
878similar to all backends (and keep them from crashing). 906and similar between tested event loop (and keep them from crashing): Glib
907would probably take thousands of years if asked to process the same number
908of watchers as EV in this benchmark.
879 909
880I<bytes> is the number of bytes (as measured by resident set size) used by 910I<bytes> is the number of bytes (as measured by the resident set size,
881each watcher. 911RSS) consumed by each watcher. This method of measuring captures both C
912and Perl-based overheads.
882 913
883I<create> is the time, in microseconds, to create a single watcher. 914I<create> is the time, in microseconds (millionths of seconds), that it
915takes to create a single watcher. The callback is a closure shared between
916all watchers, to avoid adding memory overhead. That means closure creation
917and memory usage is not included in the figures.
884 918
885I<invoke> is the time, in microseconds, used to invoke a simple callback 919I<invoke> is the time, in microseconds, used to invoke a simple
886that simply counts down. 920callback. The callback simply counts down a Perl variable and after it was
921invoked "watcher" times, it would C<< ->broadcast >> a condvar once to
922signal the end of this phase.
887 923
888I<destroy> is the time, in microseconds, to destroy a single watcher. 924I<destroy> is the time, in microseconds, that it takes to destroy a single
925watcher.
889 926
927=head2 Results
928
890 name watcher bytes create invoke destroy comment 929 name watchers bytes create invoke destroy comment
891 EV/EV 400000 244 0.56 0.46 0.31 EV native interface 930 EV/EV 400000 244 0.56 0.46 0.31 EV native interface
892 EV/Any 100000 610 3.52 0.91 0.75 931 EV/Any 100000 244 2.50 0.46 0.29 EV + AnyEvent watchers
893 CoroEV/Any 100000 610 3.49 0.92 0.75 coroutines + Coro::Signal 932 CoroEV/Any 100000 244 2.49 0.44 0.29 coroutines + Coro::Signal
894 Perl/Any 10000 654 4.64 1.22 0.77 pure perl implementation 933 Perl/Any 100000 513 4.92 0.87 1.12 pure perl implementation
895 Event/Event 10000 523 28.05 21.38 5.22 Event native interface 934 Event/Event 16000 516 31.88 31.30 0.85 Event native interface
896 Event/Any 10000 943 34.43 20.48 1.39 935 Event/Any 16000 936 39.17 33.63 1.43 Event + AnyEvent watchers
897 Glib/Any 16000 1357 96.99 12.55 55.51 quadratic behaviour 936 Glib/Any 16000 1357 98.22 12.41 54.00 quadratic behaviour
898 Tk/Any 2000 1855 27.01 66.61 14.03 SEGV with >> 2000 watchers 937 Tk/Any 2000 1860 26.97 67.98 14.00 SEGV with >> 2000 watchers
899 POE/Select 2000 6343 94.69 807.65 562.69 POE::Loop::Select
900 POE/Event 2000 6644 108.15 768.19 14.33 POE::Loop::Event 938 POE/Event 2000 6644 108.64 736.02 14.73 via POE::Loop::Event
939 POE/Select 2000 6343 94.13 809.12 565.96 via POE::Loop::Select
901 940
902Discussion: The benchmark does I<not> bench scalability of the 941=head2 Discussion
942
943The benchmark does I<not> measure scalability of the event loop very
903backend. For example a select-based backend (such as the pureperl one) can 944well. For example, a select-based event loop (such as the pure perl one)
904never compete with a backend using epoll. In this benchmark, only a single 945can never compete with an event loop that uses epoll when the number of
905filehandle is used. 946file descriptors grows high. In this benchmark, all events become ready at
947the same time, so select/poll-based implementations get an unnatural speed
948boost.
906 949
907EV is the sole leader regarding speed and memory use, which are both 950C<EV> is the sole leader regarding speed and memory use, which are both
908maximal/minimal. Even when going through AnyEvent, there is only one event 951maximal/minimal, respectively. Even when going through AnyEvent, there are
909loop that uses less memory (the Event module natively), and no faster 952only two event loops that use slightly less memory (the C<Event> module
910event model. 953natively and the pure perl backend), and no faster event models, not even
954C<Event> natively.
911 955
912The pure perl implementation is hit in a few sweet spots (both the 956The pure perl implementation is hit in a few sweet spots (both the
913zero timeout and the use of a single fd hit optimisations in the perl 957zero timeout and the use of a single fd hit optimisations in the perl
914interpreter and the backend itself), but it shows that it adds very little 958interpreter and the backend itself, and all watchers become ready at the
959same time). Nevertheless this shows that it adds very little overhead in
915overhead in itself. Like any select-based backend it's performance becomes 960itself. Like any select-based backend its performance becomes really bad
916really bad with lots of file descriptors. 961with lots of file descriptors (and few of them active), of course, but
962this was not subject of this benchmark.
917 963
918The Event module has a relatively high setup and callback invocation cost, 964The C<Event> module has a relatively high setup and callback invocation cost,
919but overall scores on the third place. 965but overall scores on the third place.
920 966
921Glib has a little higher memory cost, a bit fster callback invocation and 967C<Glib>'s memory usage is quite a bit bit higher, but it features a
922has a similar speed as Event. 968faster callback invocation and overall ends up in the same class as
969C<Event>. However, Glib scales extremely badly, doubling the number of
970watchers increases the processing time by more than a factor of four,
971making it completely unusable when using larger numbers of watchers
972(note that only a single file descriptor was used in the benchmark, so
973inefficiencies of C<poll> do not account for this).
923 974
924The Tk backend works relatively well, the fact that it crashes with 975The C<Tk> adaptor works relatively well. The fact that it crashes with
925more than 2000 watchers is a big setback, however, as correctness takes 976more than 2000 watchers is a big setback, however, as correctness takes
926precedence over speed. 977precedence over speed. Nevertheless, its performance is surprising, as the
978file descriptor is dup()ed for each watcher. This shows that the dup()
979employed by some adaptors is not a big performance issue (it does incur a
980hidden memory cost inside the kernel, though, that is not reflected in the
981figures above).
927 982
928POE, regardless of backend (wether it's pure perl select backend or the 983C<POE>, regardless of underlying event loop (wether using its pure perl
929Event backend) shows abysmal performance and memory usage: Watchers use 984select-based backend or the Event module) shows abysmal performance and
930almost 30 times as much memory as EV watchers, and 10 times as much memory 985memory usage: Watchers use almost 30 times as much memory as EV watchers,
931as both Event or EV via AnyEvent. 986and 10 times as much memory as both Event or EV via AnyEvent. Watcher
987invocation is almost 900 times slower than with AnyEvent's pure perl
988implementation. The design of the POE adaptor class in AnyEvent can not
989really account for this, as session creation overhead is small compared
990to execution of the state machine, which is coded pretty optimally within
991L<AnyEvent::Impl::POE>. POE simply seems to be abysmally slow.
932 992
993=head2 Summary
994
933Summary: using EV through AnyEvent is faster than any other event 995Using EV through AnyEvent is faster than any other event loop, but most
934loop. The overhead AnyEvent adds can be very small, and you should avoid 996event loops have acceptable performance with or without AnyEvent.
935POE like the plague if you want performance or reasonable memory usage. 997
998The overhead AnyEvent adds is usually much smaller than the overhead of
999the actual event loop, only with extremely fast event loops such as the EV
1000adds AnyEvent significant overhead.
1001
1002And you should simply avoid POE like the plague if you want performance or
1003reasonable memory usage.
936 1004
937 1005
938=head1 FORK 1006=head1 FORK
939 1007
940Most event libraries are not fork-safe. The ones who are usually are 1008Most event libraries are not fork-safe. The ones who are usually are

Diff Legend

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