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.219 by root, Thu Jun 25 11:16:08 2009 UTC vs.
Revision 1.224 by root, Fri Jul 3 21:44:14 2009 UTC

599 599
600=item $cv->begin ([group callback]) 600=item $cv->begin ([group callback])
601 601
602=item $cv->end 602=item $cv->end
603 603
604These two methods are EXPERIMENTAL and MIGHT CHANGE.
605
606These two methods can be used to combine many transactions/events into 604These two methods can be used to combine many transactions/events into
607one. For example, a function that pings many hosts in parallel might want 605one. For example, a function that pings many hosts in parallel might want
608to use a condition variable for the whole process. 606to use a condition variable for the whole process.
609 607
610Every call to C<< ->begin >> will increment a counter, and every call to 608Every call to C<< ->begin >> will increment a counter, and every call to
611C<< ->end >> will decrement it. If the counter reaches C<0> in C<< ->end 609C<< ->end >> will decrement it. If the counter reaches C<0> in C<< ->end
612>>, the (last) callback passed to C<begin> will be executed. That callback 610>>, the (last) callback passed to C<begin> will be executed. That callback
613is I<supposed> to call C<< ->send >>, but that is not required. If no 611is I<supposed> to call C<< ->send >>, but that is not required. If no
614callback was set, C<send> will be called without any arguments. 612callback was set, C<send> will be called without any arguments.
615 613
616Let's clarify this with the ping example: 614You can think of C<< $cv->send >> giving you an OR condition (one call
615sends), while C<< $cv->begin >> and C<< $cv->end >> giving you an AND
616condition (all C<begin> calls must be C<end>'ed before the condvar sends).
617
618Let's start with a simple example: you have two I/O watchers (for example,
619STDOUT and STDERR for a program), and you want to wait for both streams to
620close before activating a condvar:
621
622 my $cv = AnyEvent->condvar;
623
624 $cv->begin; # first watcher
625 my $w1 = AnyEvent->io (fh => $fh1, cb => sub {
626 defined sysread $fh1, my $buf, 4096
627 or $cv->end;
628 });
629
630 $cv->begin; # second watcher
631 my $w2 = AnyEvent->io (fh => $fh2, cb => sub {
632 defined sysread $fh2, my $buf, 4096
633 or $cv->end;
634 });
635
636 $cv->recv;
637
638This works because for every event source (EOF on file handle), there is
639one call to C<begin>, so the condvar waits for all calls to C<end> before
640sending.
641
642The ping example mentioned above is slightly more complicated, as the
643there are results to be passwd back, and the number of tasks that are
644begung can potentially be zero:
617 645
618 my $cv = AnyEvent->condvar; 646 my $cv = AnyEvent->condvar;
619 647
620 my %result; 648 my %result;
621 $cv->begin (sub { $cv->send (\%result) }); 649 $cv->begin (sub { $cv->send (\%result) });
641loop, which serves two important purposes: first, it sets the callback 669loop, which serves two important purposes: first, it sets the callback
642to be called once the counter reaches C<0>, and second, it ensures that 670to be called once the counter reaches C<0>, and second, it ensures that
643C<send> is called even when C<no> hosts are being pinged (the loop 671C<send> is called even when C<no> hosts are being pinged (the loop
644doesn't execute once). 672doesn't execute once).
645 673
646This is the general pattern when you "fan out" into multiple subrequests: 674This is the general pattern when you "fan out" into multiple (but
647use an outer C<begin>/C<end> pair to set the callback and ensure C<end> 675potentially none) subrequests: use an outer C<begin>/C<end> pair to set
648is called at least once, and then, for each subrequest you start, call 676the callback and ensure C<end> is called at least once, and then, for each
649C<begin> and for each subrequest you finish, call C<end>. 677subrequest you start, call C<begin> and for each subrequest you finish,
678call C<end>.
650 679
651=back 680=back
652 681
653=head3 METHODS FOR CONSUMERS 682=head3 METHODS FOR CONSUMERS
654 683
939no warnings; 968no warnings;
940use strict qw(vars subs); 969use strict qw(vars subs);
941 970
942use Carp; 971use Carp;
943 972
944our $VERSION = 4.412; 973our $VERSION = 4.452;
945our $MODEL; 974our $MODEL;
946 975
947our $AUTOLOAD; 976our $AUTOLOAD;
948our @ISA; 977our @ISA;
949 978
1695 EV/Any 100000 224 2.88 0.34 0.27 EV + AnyEvent watchers 1724 EV/Any 100000 224 2.88 0.34 0.27 EV + AnyEvent watchers
1696 CoroEV/Any 100000 224 2.85 0.35 0.28 coroutines + Coro::Signal 1725 CoroEV/Any 100000 224 2.85 0.35 0.28 coroutines + Coro::Signal
1697 Perl/Any 100000 452 4.13 0.73 0.95 pure perl implementation 1726 Perl/Any 100000 452 4.13 0.73 0.95 pure perl implementation
1698 Event/Event 16000 517 32.20 31.80 0.81 Event native interface 1727 Event/Event 16000 517 32.20 31.80 0.81 Event native interface
1699 Event/Any 16000 590 35.85 31.55 1.06 Event + AnyEvent watchers 1728 Event/Any 16000 590 35.85 31.55 1.06 Event + AnyEvent watchers
1729 IOAsync/Any 16000 989 38.10 32.77 11.13 via IO::Async::Loop::IO_Poll
1730 IOAsync/Any 16000 990 37.59 29.50 10.61 via IO::Async::Loop::Epoll
1700 Glib/Any 16000 1357 102.33 12.31 51.00 quadratic behaviour 1731 Glib/Any 16000 1357 102.33 12.31 51.00 quadratic behaviour
1701 Tk/Any 2000 1860 27.20 66.31 14.00 SEGV with >> 2000 watchers 1732 Tk/Any 2000 1860 27.20 66.31 14.00 SEGV with >> 2000 watchers
1702 POE/Event 2000 6328 109.99 751.67 14.02 via POE::Loop::Event 1733 POE/Event 2000 6328 109.99 751.67 14.02 via POE::Loop::Event
1703 POE/Select 2000 6027 94.54 809.13 579.80 via POE::Loop::Select 1734 POE/Select 2000 6027 94.54 809.13 579.80 via POE::Loop::Select
1704 1735
1733performance becomes really bad with lots of file descriptors (and few of 1764performance becomes really bad with lots of file descriptors (and few of
1734them active), of course, but this was not subject of this benchmark. 1765them active), of course, but this was not subject of this benchmark.
1735 1766
1736The C<Event> module has a relatively high setup and callback invocation 1767The C<Event> module has a relatively high setup and callback invocation
1737cost, but overall scores in on the third place. 1768cost, but overall scores in on the third place.
1769
1770C<IO::Async> performs admirably well, about on par with C<Event>, even
1771when using its pure perl backend.
1738 1772
1739C<Glib>'s memory usage is quite a bit higher, but it features a 1773C<Glib>'s memory usage is quite a bit higher, but it features a
1740faster callback invocation and overall ends up in the same class as 1774faster callback invocation and overall ends up in the same class as
1741C<Event>. However, Glib scales extremely badly, doubling the number of 1775C<Event>. However, Glib scales extremely badly, doubling the number of
1742watchers increases the processing time by more than a factor of four, 1776watchers increases the processing time by more than a factor of four,
1820it to another server. This includes deleting the old timeout and creating 1854it to another server. This includes deleting the old timeout and creating
1821a new one that moves the timeout into the future. 1855a new one that moves the timeout into the future.
1822 1856
1823=head3 Results 1857=head3 Results
1824 1858
1825 name sockets create request 1859 name sockets create request
1826 EV 20000 69.01 11.16 1860 EV 20000 69.01 11.16
1827 Perl 20000 73.32 35.87 1861 Perl 20000 73.32 35.87
1862 IOAsync 20000 157.00 98.14 epoll
1863 IOAsync 20000 159.31 616.06 poll
1828 Event 20000 212.62 257.32 1864 Event 20000 212.62 257.32
1829 Glib 20000 651.16 1896.30 1865 Glib 20000 651.16 1896.30
1830 POE 20000 349.67 12317.24 uses POE::Loop::Event 1866 POE 20000 349.67 12317.24 uses POE::Loop::Event
1831 1867
1832=head3 Discussion 1868=head3 Discussion
1833 1869
1834This benchmark I<does> measure scalability and overall performance of the 1870This benchmark I<does> measure scalability and overall performance of the
1835particular event loop. 1871particular event loop.
1837EV is again fastest. Since it is using epoll on my system, the setup time 1873EV is again fastest. Since it is using epoll on my system, the setup time
1838is relatively high, though. 1874is relatively high, though.
1839 1875
1840Perl surprisingly comes second. It is much faster than the C-based event 1876Perl surprisingly comes second. It is much faster than the C-based event
1841loops Event and Glib. 1877loops Event and Glib.
1878
1879IO::Async performs very well when using its epoll backend, and still quite
1880good compared to Glib when using its pure perl backend.
1842 1881
1843Event suffers from high setup time as well (look at its code and you will 1882Event suffers from high setup time as well (look at its code and you will
1844understand why). Callback invocation also has a high overhead compared to 1883understand why). Callback invocation also has a high overhead compared to
1845the C<< $_->() for .. >>-style loop that the Perl event loop uses. Event 1884the C<< $_->() for .. >>-style loop that the Perl event loop uses. Event
1846uses select or poll in basically all documented configurations. 1885uses select or poll in basically all documented configurations.

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines