AnyEvent
view release on metacpan or search on metacpan
101810191020102110221023102410251026102710281029103010311032103310341035103610371038
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.
18311832183318341835183618371838183918401841184218431844184518461847184818491850IO::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
272727282729273027312732273327342735273627372738273927402741274227432744274527462747IO::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
24122413241424152416241724182419242024212422242324242425242624272428242924302431See 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
6667686970717273747576777879808182838485time
, 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
858687888990919293949596979899100101102103104
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
15101511151215131514151515161517151815191520152115221523152415251526152715281529This 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 )