[ViewVC] Diff of: cvs/AnyEvent/lib/AnyEvent.pm

Comparing AnyEvent/lib/AnyEvent.pm (file contents):
Revision 1.99 by root, Sun Apr 27 17:09:33 2008 UTC vs.
Revision 1.104 by root, Wed Apr 30 11:40:22 2008 UTC

 technically possible.
 Of course, if you want lots of policy (this can arguably be somewhat
 useful) and you want to force your users to use the one and only event
 model, you should I<not> use this module.
-#TODO#
-Net::IRC3
-AnyEvent::HTTPD
-AnyEvent::DNS
-IO::AnyEvent
-Net::FPing
-Net::XMPP2
-Coro
-AnyEvent::IRC
-AnyEvent::HTTPD
-AnyEvent::DNS
-AnyEvent::Handle
-AnyEvent::Socket
-AnyEvent::FPing
-AnyEvent::XMPP
-AnyEvent::SNMP
-Coro
 =head1 DESCRIPTION
 L<AnyEvent> provides an identical interface to multiple event loops. This
 allows module authors to utilise an event loop without forcing module
    AnyEvent::Impl::CoroEV    based on Coro::EV, best choice.
    AnyEvent::Impl::CoroEvent based on Coro::Event, second best choice.
    AnyEvent::Impl::EV        based on EV (an interface to libev, best choice).
    AnyEvent::Impl::Event     based on Event, second best choice.
+   AnyEvent::Impl::Perl      pure-perl implementation, fast and portable.
    AnyEvent::Impl::Glib      based on Glib, third-best choice.
-   AnyEvent::Impl::Perl      pure-perl implementation, inefficient but portable.
    AnyEvent::Impl::Tk        based on Tk, very bad choice.
    AnyEvent::Impl::Qt        based on Qt, cannot be autoprobed (see its docs).
    AnyEvent::Impl::EventLib  based on Event::Lib, leaks memory and worse.
    AnyEvent::Impl::POE       based on POE, not generic enough for full support.
 You can chose to use a rather inefficient pure-perl implementation by
 loading the C<AnyEvent::Impl::Perl> module, which gives you similar
 behaviour everywhere, but letting AnyEvent chose is generally better.
+=head1 OTHER MODULES
+The following is a non-exhaustive list of additional modules that use
+AnyEvent and can therefore be mixed easily with other AnyEvent modules
+in the same program. Some of the modules come with AnyEvent, some are
+available via CPAN.
+=over 4
+=item L<AnyEvent::Util>
+Contains various utility functions that replace often-used but blocking
+functions such as C<inet_aton> by event-/callback-based versions.
+=item L<AnyEvent::Handle>
+Provide read and write buffers and manages watchers for reads and writes.
+=item L<AnyEvent::Socket>
+Provides a means to do non-blocking connects, accepts etc.
+=item L<AnyEvent::HTTPD>
+Provides a simple web application server framework.
+=item L<AnyEvent::DNS>
+Provides asynchronous DNS resolver capabilities, beyond what
+L<AnyEvent::Util> offers.
+=item L<AnyEvent::FastPing>
+The fastest ping in the west.
+=item L<Net::IRC3>
+AnyEvent based IRC client module family.
+=item L<Net::XMPP2>
+AnyEvent based XMPP (Jabber protocol) module family.
+=item L<Net::FCP>
+AnyEvent-based implementation of the Freenet Client Protocol, birthplace
+of AnyEvent.
+=item L<Event::ExecFlow>
+High level API for event-based execution flow control.
+=item L<Coro>
+Has special support for AnyEvent.
+=item L<IO::Lambda>
+The lambda approach to I/O - don't ask, look there. Can use AnyEvent.
+=item L<IO::AIO>
+Truly asynchronous I/O, should be in the toolbox of every event
+programmer. Can be trivially made to use AnyEvent.
+=item L<BDB>
+Truly asynchronous Berkeley DB access. Can be trivially made to use
+AnyEvent.
+=back
 =cut
 package AnyEvent;
 no warnings;
 my @models = (
    [Coro::EV::             => AnyEvent::Impl::CoroEV::],
    [Coro::Event::          => AnyEvent::Impl::CoroEvent::],
    [EV::                   => AnyEvent::Impl::EV::],
    [Event::                => AnyEvent::Impl::Event::],
-   [Glib::                 => AnyEvent::Impl::Glib::],
    [Tk::                   => AnyEvent::Impl::Tk::],
    [Wx::                   => AnyEvent::Impl::POE::],
    [Prima::                => AnyEvent::Impl::POE::],
    [AnyEvent::Impl::Perl:: => AnyEvent::Impl::Perl::],
    # everything below here will not be autoprobed as the pureperl backend should work everywhere
+   [Glib::                 => AnyEvent::Impl::Glib::],
    [Event::Lib::           => AnyEvent::Impl::EventLib::], # too buggy
    [Qt::                   => AnyEvent::Impl::Qt::],       # requires special main program
    [POE::Kernel::          => AnyEvent::Impl::POE::],      # lasciate ogni speranza
 );
 file descriptor is dup()ed for each watcher. This shows that the dup()
 employed by some adaptors is not a big performance issue (it does incur a
 hidden memory cost inside the kernel which is not reflected in the figures
 above).
-C<POE>, regardless of underlying event loop (whether using its pure
+C<POE>, regardless of underlying event loop (whether using its pure perl
-perl select-based backend or the Event module, the POE-EV backend
+select-based backend or the Event module, the POE-EV backend couldn't
-couldn't be tested because it wasn't working) shows abysmal performance
+be tested because it wasn't working) shows abysmal performance and
-and memory usage: Watchers use almost 30 times as much memory as
+memory usage with AnyEvent: Watchers use almost 30 times as much memory
-EV watchers, and 10 times as much memory as Event (the high memory
+as EV watchers, and 10 times as much memory as Event (the high memory
 requirements are caused by requiring a session for each watcher). Watcher
 invocation speed is almost 900 times slower than with AnyEvent's pure perl
+implementation.
-implementation. The design of the POE adaptor class in AnyEvent can not
+The design of the POE adaptor class in AnyEvent can not really account
-really account for this, as session creation overhead is small compared
+for the performance issues, though, as session creation overhead is
-to execution of the state machine, which is coded pretty optimally within
+small compared to execution of the state machine, which is coded pretty
-L<AnyEvent::Impl::POE>. POE simply seems to be abysmally slow.
+optimally within L<AnyEvent::Impl::POE> (and while everybody agrees that
+using multiple sessions is not a good approach, especially regarding
+memory usage, even the author of POE could not come up with a faster
+design).
 =head3 Summary
 =over 4
 =head3 Summary
 =over 4
-=item * The pure perl implementation performs extremely well, considering
+=item * The pure perl implementation performs extremely well.
-that it uses select.
 =item * Avoid Glib or POE in large projects where performance matters.
 =back
 speed most when you have lots of watchers, not when you only have a few of
 them).
 EV is again fastest.
-The C-based event loops Event and Glib come in second this time, as the
+Perl again comes second. It is noticably faster than the C-based event
-overhead of running an iteration is much smaller in C than in Perl (little
+loops Event and Glib, although the difference is too small to really
-code to execute in the inner loop, and perl's function calling overhead is
+matter.
-high, and updating all the data structures is costly).
-The pure perl event loop is much slower, but still competitive.
 POE also performs much better in this case, but is is still far behind the
 others.
 =head3 Summary
 =head1 FORK
 Most event libraries are not fork-safe. The ones who are usually are
-because they are so inefficient. Only L<EV> is fully fork-aware.
+because they rely on inefficient but fork-safe C<select> or C<poll>
+calls. Only L<EV> is fully fork-aware.
 If you have to fork, you must either do so I<before> creating your first
 watcher OR you must not use AnyEvent at all in the child.

Diff Legend

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

Comparing AnyEvent/lib/AnyEvent.pm (file contents): Revision 1.99 by root, Sun Apr 27 17:09:33 2008 UTC vs. Revision 1.104 by root, Wed Apr 30 11:40:22 2008 UTC

Diff Legend

Comparing AnyEvent/lib/AnyEvent.pm (file contents):
Revision 1.99 by root, Sun Apr 27 17:09:33 2008 UTC vs.
Revision 1.104 by root, Wed Apr 30 11:40:22 2008 UTC