AnyEvent

 view release on metacpan or  search on metacpan

Changes  view on Meta::CPAN

1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
          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

1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
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

2727
2728
2729
2730
2731
2732
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743
2744
2745
2746
2747
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

2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
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

66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
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

85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
      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

1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
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>
 
=cut
 
1



( run in 0.419 second using v1.01-cache-2.11-cpan-2b0bae70ee8 )