AnyEvent

 view release on metacpan or  search on metacpan

Changes  view on Meta::CPAN

          microsoft, the current broken-dns-config-king.
        - AnyEvent::DNS didn't check for socket return status
          but instead relied on perl not creating filehandles in that
          case - too bad it gives you a bogus file handle (reported
          and analysed by Vladimir Timofeev).
	- fix queue management logic in AnyEvent::Handle:
          when on_read was registered, the queue was empty
          and no progress could be made AnyEvent::Handle would
          enter an endless loop.
        - correctly start reading again when the handle became
          busy again after idling.
        - correctly treat tls shut-downs as EOF condition
          (for the time being, would be nice to have a callback for that).
        - correctly call eof callback under all conditions
          (hopefully).
        - the timeout callback did not expect that $self can go
          away any time.

4.12 Tue Jun  3 10:58:04 CEST 2008
	- include AnyEvent::Intro, a tutorial for anyevent,
          anyevent::socket and anyevent::handle.

README  view on Meta::CPAN

    IO::Async performs very well when using its epoll backend, and still
    quite good compared to Glib when using its pure perl backend.

    Event suffers from high setup time as well (look at its code and you
    will understand why). Callback invocation also has a high overhead
    compared to the "$_->() for .."-style loop that the Perl event loop
    uses. Event uses select or poll in basically all documented
    configurations.

    Glib is hit hard by its quadratic behaviour w.r.t. many watchers. It
    clearly fails to perform with many filehandles or in busy servers.

    POE is still completely out of the picture, taking over 1000 times as
    long as EV, and over 100 times as long as the Perl implementation, even
    though it uses a C-based event loop in this case.

   Summary
    *   The pure perl implementation performs extremely well.

    *   Avoid Glib or POE in large projects where performance matters.

lib/AnyEvent.pm  view on Meta::CPAN

IO::Async performs very well when using its epoll backend, and still quite
good compared to Glib when using its pure perl backend.

Event suffers from high setup time as well (look at its code and you will
understand why). Callback invocation also has a high overhead compared to
the C<< $_->() for .. >>-style loop that the Perl event loop uses. Event
uses select or poll in basically all documented configurations.

Glib is hit hard by its quadratic behaviour w.r.t. many watchers. It
clearly fails to perform with many filehandles or in busy servers.

POE is still completely out of the picture, taking over 1000 times as long
as EV, and over 100 times as long as the Perl implementation, even though
it uses a C-based event loop in this case.

=head3 Summary

=over 4

=item * The pure perl implementation performs extremely well.

lib/AnyEvent/Handle.pm  view on Meta::CPAN

See also the next question, which explains this in a bit more detail.

=item How can I serve requests in a loop?

Most protocols consist of some setup phase (authentication for example)
followed by a request handling phase, where the server waits for requests
and handles them, in a loop.

There are two important variants: The first (traditional, better) variant
handles requests until the server gets some QUIT command, causing it to
close the connection first (highly desirable for a busy TCP server). A
client dropping the connection is an error, which means this variant can
detect an unexpected detection close.

To handle this case, always make sure you have a non-empty read queue, by
pushing the "read request start" handler on it:

   # we assume a request starts with a single line
   my @start_request; @start_request = (line => sub {
      my ($hdl, $line) = @_;

lib/AnyEvent/IO.pm  view on Meta::CPAN

Unlike L<AnyEvent>, which model to use is currently decided at module load
time, not at first use. Future releases might change this.

=head2 RATIONALE

While disk I/O often seems "instant" compared to, say, socket I/O, there
are many situations where your program can block for extended time periods
when doing disk I/O. For example, you access a disk on an NFS server and
it is gone - can take ages to respond again, if ever. Or your system is
extremely busy because it creates or restores a backup - reading data from
disk can then take seconds. Or you use Linux, which for so many years has
a close-to-broken VM/IO subsystem that can often induce minutes or more of
delay for disk I/O, even under what I would consider light I/O loads.

Whatever the situation, some programs just can't afford to block for long
times (say, half a second or more), because they need to respond as fast
as possible.

For those cases, you need asynchronous I/O.

lib/AnyEvent/Impl/FLTK.pm  view on Meta::CPAN

      FLTK::WRITE | (AnyEvent::WIN32 ? FLTK::EXCEPT : 0);

   # fltk hardcodes poll constants and aliases EXCEPT with POLLERR,
   # which is grossly wrong, but likely it doesn't use poll on windows.
   FLTK::add_fd $fh, $ev, sub { &$cb }
}

# use signal and child emulation - fltk has no facilities for that

# fltk idle watchers are like EV::check watchers, and fltk check watchers
# are like EV::prepare watchers. both are called when the loop is busy,
# so we have to use idle watcher emulation.

sub _poll {
   FLTK::wait;
}

sub AnyEvent::CondVar::Base::_wait {
   FLTK::wait until exists $_[0]{_ae_sent};
}

lib/AnyEvent/Log.pm  view on Meta::CPAN

This of course works for any package, not just L<AnyEvent::Debug>, but
assumes the log level for AnyEvent::Debug hasn't been changed from the
default.

=back

=head1 ASYNCHRONOUS DISK I/O

This module uses L<AnyEvent::IO> to actually write log messages (in
C<log_to_file> and C<log_to_path>), so it doesn't block your program when
the disk is busy and a non-blocking L<AnyEvent::IO> backend is available.

=head1 AUTHOR

 Marc Lehmann <schmorp@schmorp.de>
 http://anyevent.schmorp.de

=cut

1