AnyEvent
view release on metacpan or search on metacpan
actually doing all I/O *synchronously*...), using them in your module is
like joining a cult: After you join, you are dependent on them and you
cannot use anything else, as they are simply incompatible to everything
that isn't them. What's worse, all the potential users of your module
are *also* forced to use the same event loop you use.
AnyEvent is different: AnyEvent + POE works fine. AnyEvent + Glib works
fine. AnyEvent + Tk works fine etc. etc. but none of these work together
with the rest: POE + EV? No go. Tk + Event? No go. Again: if your module
uses one of those, every user of your module has to use it, too. But if
your module uses AnyEvent, it works transparently with all event models
it supports (including stuff like IO::Async, as long as those use one of
the supported event loops. It is easy to add new event loops to
AnyEvent, too, so it is future-proof).
In addition to being free of having to use *the one and only true event
model*, AnyEvent also is free of bloat and policy: with POE or similar
modules, you get an enormous amount of code and strict rules you have to
follow. AnyEvent, on the other hand, is lean and to the point, by only
offering the functionality that is necessary, in as thin as a wrapper as
technically possible.
Backends that are autoprobed when no other event loop can be found.
EV is the preferred backend when no other event loop seems to be in
use. If EV is not installed, then AnyEvent will fall back to its own
pure-perl implementation, which is available everywhere as it comes
with AnyEvent itself.
AnyEvent::Impl::EV based on EV (interface to libev, best choice).
AnyEvent::Impl::Perl pure-perl AnyEvent::Loop, fast and portable.
Backends that are transparently being picked up when they are used.
These will be used if they are already loaded when the first watcher
is created, in which case it is assumed that the application is
using them. This means that AnyEvent will automatically pick the
right backend when the main program loads an event module before
anything starts to create watchers. Nothing special needs to be done
by the main program.
AnyEvent::Impl::Event based on Event, very stable, few glitches.
AnyEvent::Impl::Glib based on Glib, slow but very stable.
AnyEvent::Impl::Tk based on Tk, very broken.
AnyEvent::Socket (part of the AnyEvent distribution)
Provides various utility functions for (internet protocol) sockets,
addresses and name resolution. Also functions to create non-blocking
tcp connections or tcp servers, with IPv6 and SRV record support and
more.
AnyEvent::Handle (part of the AnyEvent distribution)
Provide read and write buffers, manages watchers for reads and
writes, supports raw and formatted I/O, I/O queued and fully
transparent and non-blocking SSL/TLS (via AnyEvent::TLS).
AnyEvent::DNS (part of the AnyEvent distribution)
Provides rich asynchronous DNS resolver capabilities.
AnyEvent::HTTP, AnyEvent::IRC, AnyEvent::XMPP, AnyEvent::GPSD,
AnyEvent::IGS, AnyEvent::FCP
Implement event-based interfaces to the protocols of the same name
(for the curious, IGS is the International Go Server and FCP is the
Freenet Client Protocol).
AnyEvent::AIO (part of the AnyEvent distribution)
Truly asynchronous (as opposed to non-blocking) I/O, should be in
the toolbox of every event programmer. AnyEvent::AIO transparently
fuses IO::AIO and AnyEvent together, giving AnyEvent access to
event-based file I/O, and much more.
AnyEvent::Fork, AnyEvent::Fork::RPC, AnyEvent::Fork::Pool,
AnyEvent::Fork::Remote
These let you safely fork new subprocesses, either locally or
remotely (e.g.v ia ssh), using some RPC protocol or not, without the
limitations normally imposed by fork (AnyEvent works fine for
example). Dynamically-resized worker pools are obviously included as
well.
just to exec external programs can easily beat using "fork" and
"exec" (or even "system") in most programs.
AnyEvent::Filesys::Notify
AnyEvent is good for non-blocking stuff, but it can't detect file or
path changes (e.g. "watch this directory for new files", "watch this
file for changes"). The AnyEvent::Filesys::Notify module promises to
do just that in a portbale fashion, supporting inotify on GNU/Linux
and some weird, without doubt broken, stuff on OS X to monitor
files. It can fall back to blocking scans at regular intervals
transparently on other platforms, so it's about as portable as it
gets.
(I haven't used it myself, but it seems the biggest problem with it
is it quite bad performance).
AnyEvent::DBI
Executes DBI requests asynchronously in a proxy process for you,
notifying you in an event-based way when the operation is finished.
AnyEvent::FastPing
lib/AnyEvent.pm view on Meta::CPAN
actually doing all I/O I<synchronously>...), using them in your module is
like joining a cult: After you join, you are dependent on them and you
cannot use anything else, as they are simply incompatible to everything
that isn't them. What's worse, all the potential users of your
module are I<also> forced to use the same event loop you use.
AnyEvent is different: AnyEvent + POE works fine. AnyEvent + Glib works
fine. AnyEvent + Tk works fine etc. etc. but none of these work together
with the rest: POE + EV? No go. Tk + Event? No go. Again: if your module
uses one of those, every user of your module has to use it, too. But if
your module uses AnyEvent, it works transparently with all event models it
supports (including stuff like IO::Async, as long as those use one of the
supported event loops. It is easy to add new event loops to AnyEvent, too,
so it is future-proof).
In addition to being free of having to use I<the one and only true event
model>, AnyEvent also is free of bloat and policy: with POE or similar
modules, you get an enormous amount of code and strict rules you have to
follow. AnyEvent, on the other hand, is lean and to the point, by only
offering the functionality that is necessary, in as thin as a wrapper as
technically possible.
lib/AnyEvent.pm view on Meta::CPAN
=item Backends that are autoprobed when no other event loop can be found.
EV is the preferred backend when no other event loop seems to be in
use. If EV is not installed, then AnyEvent will fall back to its own
pure-perl implementation, which is available everywhere as it comes with
AnyEvent itself.
AnyEvent::Impl::EV based on EV (interface to libev, best choice).
AnyEvent::Impl::Perl pure-perl AnyEvent::Loop, fast and portable.
=item Backends that are transparently being picked up when they are used.
These will be used if they are already loaded when the first watcher
is created, in which case it is assumed that the application is using
them. This means that AnyEvent will automatically pick the right backend
when the main program loads an event module before anything starts to
create watchers. Nothing special needs to be done by the main program.
AnyEvent::Impl::Event based on Event, very stable, few glitches.
AnyEvent::Impl::Glib based on Glib, slow but very stable.
AnyEvent::Impl::Tk based on Tk, very broken.
lib/AnyEvent.pm view on Meta::CPAN
=item L<AnyEvent::Socket> (part of the AnyEvent distribution)
Provides various utility functions for (internet protocol) sockets,
addresses and name resolution. Also functions to create non-blocking tcp
connections or tcp servers, with IPv6 and SRV record support and more.
=item L<AnyEvent::Handle> (part of the AnyEvent distribution)
Provide read and write buffers, manages watchers for reads and writes,
supports raw and formatted I/O, I/O queued and fully transparent and
non-blocking SSL/TLS (via L<AnyEvent::TLS>).
=item L<AnyEvent::DNS> (part of the AnyEvent distribution)
Provides rich asynchronous DNS resolver capabilities.
=item L<AnyEvent::HTTP>, L<AnyEvent::IRC>, L<AnyEvent::XMPP>, L<AnyEvent::GPSD>, L<AnyEvent::IGS>, L<AnyEvent::FCP>
Implement event-based interfaces to the protocols of the same name (for
the curious, IGS is the International Go Server and FCP is the Freenet
Client Protocol).
=item L<AnyEvent::AIO> (part of the AnyEvent distribution)
Truly asynchronous (as opposed to non-blocking) I/O, should be in the
toolbox of every event programmer. AnyEvent::AIO transparently fuses
L<IO::AIO> and AnyEvent together, giving AnyEvent access to event-based
file I/O, and much more.
=item L<AnyEvent::Fork>, L<AnyEvent::Fork::RPC>, L<AnyEvent::Fork::Pool>, L<AnyEvent::Fork::Remote>
These let you safely fork new subprocesses, either locally or
remotely (e.g.v ia ssh), using some RPC protocol or not, without
the limitations normally imposed by fork (AnyEvent works fine for
example). Dynamically-resized worker pools are obviously included as well.
lib/AnyEvent.pm view on Meta::CPAN
just to exec external programs can easily beat using C<fork> and C<exec>
(or even C<system>) in most programs.
=item L<AnyEvent::Filesys::Notify>
AnyEvent is good for non-blocking stuff, but it can't detect file or
path changes (e.g. "watch this directory for new files", "watch this
file for changes"). The L<AnyEvent::Filesys::Notify> module promises to
do just that in a portbale fashion, supporting inotify on GNU/Linux and
some weird, without doubt broken, stuff on OS X to monitor files. It can
fall back to blocking scans at regular intervals transparently on other
platforms, so it's about as portable as it gets.
(I haven't used it myself, but it seems the biggest problem with it is
it quite bad performance).
=item L<AnyEvent::DBI>
Executes L<DBI> requests asynchronously in a proxy process for you,
notifying you in an event-based way when the operation is finished.
lib/AnyEvent.pm view on Meta::CPAN
undef
};
$MODEL
}
for my $name (@methods) {
*$name = sub {
detect;
# we use goto because
# a) it makes the thunk more transparent
# b) it allows us to delete the thunk later
goto &{ UNIVERSAL::can AnyEvent => "SUPER::$name" }
};
}
# utility function to dup a filehandle. this is used by many backends
# to support binding more than one watcher per filehandle (they usually
# allow only one watcher per fd, so we dup it to get a different one).
sub _dupfh($$;$$) {
my ($poll, $fh, $r, $w) = @_;
lib/AnyEvent/DNS.pm view on Meta::CPAN
=item AnyEvent::DNS::ptr $domain, $cb->(@hostnames)
Tries to make a PTR lookup on the given domain. See C<reverse_lookup>
and C<reverse_verify> if you want to resolve an IP address to a hostname
instead.
=item AnyEvent::DNS::reverse_lookup $ipv4_or_6, $cb->(@hostnames)
Tries to reverse-resolve the given IPv4 or IPv6 address (in textual form)
into its hostname(s). Handles V4MAPPED and V4COMPAT IPv6 addresses
transparently.
=item AnyEvent::DNS::reverse_verify $ipv4_or_6, $cb->(@hostnames)
The same as C<reverse_lookup>, but does forward-lookups to verify that
the resolved hostnames indeed point to the address, which makes spoofing
harder.
If you want to resolve an address into a hostname, this is the preferred
method: The DNS records could still change, but at least this function
verified that the hostname, at one point in the past, pointed at the IP
lib/AnyEvent/Handle.pm view on Meta::CPAN
Apart from being useful in error messages, this string is also used in TLS
peername verification (see C<verify_peername> in L<AnyEvent::TLS>). This
verification will be skipped when C<peername> is not specified or is
C<undef>.
=item tls => "accept" | "connect" | Net::SSLeay::SSL object
When this parameter is given, it enables TLS (SSL) mode, that means
AnyEvent will start a TLS handshake as soon as the connection has been
established and will transparently encrypt/decrypt data afterwards.
All TLS protocol errors will be signalled as C<EPROTO>, with an
appropriate error message.
TLS mode requires Net::SSLeay to be installed (it will be loaded
automatically when you try to create a TLS handle): this module doesn't
have a dependency on that module, so if your module requires it, you have
to add the dependency yourself. If Net::SSLeay cannot be loaded or is too
old, you get an C<EPROTO> error.
lib/AnyEvent/Impl/EV.pm view on Meta::CPAN
=head1 SYNOPSIS
use AnyEvent;
use EV;
# this module gets loaded automatically as required
=head1 DESCRIPTION
This module provides transparent support for AnyEvent. You don't have to
do anything to make EV work with AnyEvent except by loading EV before
creating the first AnyEvent watcher.
EV is the fastest event library for perl, and best supported by
AnyEvent. Most functions from the L<AE> API are implemented as direct
aliases to EV functions, so using EV via AE is as fast as using EV
directly.
=cut
lib/AnyEvent/Impl/Event.pm view on Meta::CPAN
=head1 SYNOPSIS
use AnyEvent;
use Event;
# this module gets loaded automatically as required
=head1 DESCRIPTION
This module provides transparent support for AnyEvent. You don't have to
do anything to make Event work with AnyEvent except by loading Event before
creating the first AnyEvent watcher.
The event module is reasonably efficient and generally works correctly
even with many watchers, except that its signal handling is inherently
racy and requires the wake-up-frequently workaround.
=cut
package AnyEvent::Impl::Event;
lib/AnyEvent/Impl/EventLib.pm view on Meta::CPAN
=head1 SYNOPSIS
use AnyEvent;
use Event::Lib;
# this module gets loaded automatically as required
=head1 DESCRIPTION
This module provides transparent support for AnyEvent. You don't have to
do anything to make Event work with AnyEvent except by loading Event::Lib
before creating the first AnyEvent watcher.
Note: the AnyEvent author has not found recent releases of Event::Lib to
be even remotely working (not even the examples from the manpage or the
testsuite work), so this event backend should be avoided (or somebody
should step up and maintain it, hint, hint).
The L<Event::Lib> module suffers from the same limitations and bugs as
libevent, most notably it kills already-installed watchers on a file
lib/AnyEvent/Impl/FLTK.pm view on Meta::CPAN
=head1 SYNOPSIS
use AnyEvent;
use FLTK;
# this module gets loaded automatically as required
=head1 DESCRIPTION
This module provides transparent support for AnyEvent. You don't have to
do anything to make FLTK work with AnyEvent except by loading FLTK before
creating the first AnyEvent watcher.
This implementation is not to be confused with AnyEvent::Impl::FLTK by
Sanko Robinson. That implementation is completely broken, and the author
is apparently unreachable.
In any case, FLTK suffers from typical GUI-ToolKit diseases, such as O(n)
or worse for every operation (adding a timer, destroying a timer etc.),
the typical Not-Well-Tested Perl Interface disases such as non-random
lib/AnyEvent/Impl/Glib.pm view on Meta::CPAN
=head1 SYNOPSIS
use AnyEvent;
use Glib;
# this module gets loaded automatically as required
=head1 DESCRIPTION
This module provides transparent support for AnyEvent. You don't have to
do anything to make Glib work with AnyEvent except by loading Glib before
creating the first AnyEvent watcher.
Glib is probably the most inefficient event loop that has ever seen the
light of the world: Glib not only scans all its watchers (really, ALL of
them, whether I/O-related, timer-related or what not) during each loop
iteration, it also does so multiple times and rebuilds the poll list for
the kernel each time again, dynamically even. Newer versions of libglib
fortunately do not call malloc/free on every single watcher invocation,
though.
lib/AnyEvent/Impl/IOAsync.pm view on Meta::CPAN
The only user-servicible part in this module is the C<set_loop> function
and C<$LOOP> variable:
=over 4
=item AnyEvent::Impl::IOAsync::set_loop $new_loop
Unfortunately, IO::Async has no concept of a default loop. Modules using
IO::Async must be told by their caller which loop to use, which makes it
impossible to transparently use IO::Async from a module.
This module is no exception. It creates a new IO::Async::Loop object when
it is loaded. This might not be the right loop object, though, and thus
you can replace it by a call to this function with the loop object of your
choice.
Note that switching loops while watchers are already initialised can have
unexpected effects, and is not supported unless you can live witht he
consequences.
=item $AnyEvent::Impl::IOAsync::LOOP
This variable always contains the IO::Async::Loop object used by this
AnyEvent backend. See above for more info.
Storing the "default" loop makes this module a possible arbiter for other
modules that want to use IO::Async transparently. It's advised to directly
refer to this variable each time you want to use it, without making a
local copy.
=back
=head1 PROBLEMS WITH IO::Async
This section had a long list of problems and shortcomings that made it
almost impossible to support L<IO::Async>. With version 0.33 of IO::Async,
however, most of these have been fixed, so L<IO::Async> can now be used as
lib/AnyEvent/Impl/Irssi.pm view on Meta::CPAN
AnyEvent::Impl::Irssi - AnyEvent adaptor for Irssi
=head1 SYNOPSIS
use AnyEvent;
# this module gets loaded automatically when running under irssi
=head1 DESCRIPTION
This module provides transparent support for AnyEvent. You don't have to
do anything to make Irssi scripts work with AnyEvent.
Limitations of this backend and implementation details:
=over 4
=item * This backend does not support blocking waits.
That means you must set a callback on any condvars, or otherwise make sure
to never call C<recv> on a condvar that hasn't been signalled yet.
lib/AnyEvent/Impl/POE.pm view on Meta::CPAN
=head1 SYNOPSIS
use AnyEvent;
use POE;
# this module gets loaded automatically as required
=head1 DESCRIPTION
This module provides transparent support for AnyEvent. You don't have to
do anything to make POE work with AnyEvent except by loading POE before
creating the first AnyEvent watcher. There are some cases where POE will
issue spurious (and non-suppressible) warnings. These can be avoided by
loading AnyEvent::Impl::POE before loading any other modules using POE and
AnyEvent, i.e. in your main program.
AnyEvent::Impl::POE will output some spurious message how to work around
POE's spurious messages when it detects these cases.
Unfortunately, POE isn't generic enough to implement a fully working
lib/AnyEvent/Impl/Perl.pm view on Meta::CPAN
AnyEvent::Impl::Perl - AnyEvent adaptor for AnyEvent's pure perl AnyEvent::Loop
=head1 SYNOPSIS
use AnyEvent;
use AnyEvent::Loop;
# this module gets loaded automatically as required
=head1 DESCRIPTION
This module provides transparent support for AnyEvent in case no other
event loop could be found or loaded.
If you want to use this module instead of autoloading another event loop
you can simply load L<AnyEvent::Loop> before creating the first watcher.
Naturally, it supports all features of AnyEvent.
See L<AnyEvent::Loop> for more details on performance characteristics.
=cut
lib/AnyEvent/Impl/Qt.pm view on Meta::CPAN
use AnyEvent;
use Qt;
my $app = Qt::Application \@ARGV; # REQUIRED!
# this module gets loaded automatically as required
=head1 DESCRIPTION
This module provides transparent support for AnyEvent. You don't have
to do anything to make Qt work with AnyEvent except by loading Qt
before creating the first AnyEvent watcher I<and instantiating the
Qt::Application object>. Failure to do so will result in segfaults,
which is why this model doesn't work as a default model and will not be
autoprobed (but it will be autodetected when the main program uses Qt).
Qt suffers from the same limitations as Event::Lib and Tk, the workaround
is also the same (duplicating file descriptors).
Qt doesn't support idle events, so they are being emulated.
lib/AnyEvent/Impl/Tk.pm view on Meta::CPAN
=head1 SYNOPSIS
use AnyEvent;
use Tk;
# this module gets loaded automatically as required
=head1 DESCRIPTION
This module provides transparent support for AnyEvent. You don't have to
do anything to make Tk work with AnyEvent except by loading Tk before
creating the first AnyEvent watcher.
Tk is buggy. Tk is extremely buggy. Tk is so unbelievably buggy that
for each bug reported and fixed, you get one new bug followed by
reintroduction of the old bug in a later revision. It is also basically
unmaintained: the maintainers are not even interested in improving
the situation - reporting bugs is considered rude, and fixing bugs is
considered changing holy code, so it's apparently better to leave it
broken.
lib/AnyEvent/Impl/UV.pm view on Meta::CPAN
=head1 SYNOPSIS
use AnyEvent;
use UV;
# this module gets loaded automatically as required
=head1 DESCRIPTION
This module provides transparent support for AnyEvent. You don't have to
do anything to make UV work with AnyEvent except by loading UV before
creating the first AnyEvent watcher.
=cut
package AnyEvent::Impl::UV;
use AnyEvent (); BEGIN { AnyEvent::common_sense }
use UV 0.24;
use Scalar::Util qw(weaken);
lib/AnyEvent/Intro.pod view on Meta::CPAN
fixed and variable-width data blocks.
=head2 L<AnyEvent::Socket>
This module provides you with functions that handle socket creation
and IP address magic. The two main functions are C<tcp_connect> and
C<tcp_server>. The former will connect a (streaming) socket to an internet
host for you and the later will make a server socket for you, to accept
connections.
This module also comes with transparent IPv6 support, this means: If you
write your programs with this module, you will be IPv6 ready without doing
anything special.
It also works around a lot of portability quirks (especially on the
windows platform), which makes it even easier to write your programs in a
portable way (did you know that windows uses different error codes for all
socket functions and that Perl does not know about these? That "Unknown
error 10022" (which is C<WSAEINVAL>) can mean that our C<connect> call was
successful? That unsuccessful TCP connects might never be reported back
to your program? That C<WSAEINPROGRESS> means your C<connect> call was
lib/AnyEvent/Intro.pod view on Meta::CPAN
tls => "connect",
Specifying C<tls> enables TLS, and the argument specifies whether
AnyEvent::Handle is the server side ("accept") or the client side
("connect") for the TLS connection, as unlike TCP, there is a clear
server/client relationship in TLS.
That's all.
Of course, all this should be handled transparently by C<http_get>
after parsing the URL. If you need this, see the part about exercising
your inspiration earlier in this document. You could also use the
L<AnyEvent::HTTP> module from CPAN, which implements all this and works
around a lot of quirks for you too.
=head3 The read queue - revisited
HTTP always uses the same structure in its responses, but many protocols
require parsing responses differently depending on the response itself.
lib/AnyEvent/Socket.pm view on Meta::CPAN
# a simple tcp server
tcp_server undef, 8888, sub {
my ($fh, $host, $port) = @_;
syswrite $fh, "The internet is full, $host:$port. Go away!\015\012";
};
=head1 DESCRIPTION
This module implements various utility functions for handling internet
protocol addresses and sockets, in an as transparent and simple way as
possible.
All functions documented without C<AnyEvent::Socket::> prefix are exported
by default.
=over 4
=cut
package AnyEvent::Socket;
( run in 0.636 second using v1.01-cache-2.11-cpan-a1d94b6210f )