IO::Async::LoopTests(3pm) User Contributed Perl Documentation IO::Async::LoopTests(3pm)NAME
"IO::Async::LoopTests" - acceptance testing for "IO::Async::Loop" subclasses
SYNOPSIS
use IO::Async::LoopTests;
run_tests( 'IO::Async::Loop::Shiney', 'io' );
DESCRIPTION
This module contains a collection of test functions for running acceptance tests on IO::Async::Loop subclasses. It is provided as a
facility for authors of such subclasses to ensure that the code conforms to the Loop API required by "IO::Async".
TIMING
Certain tests require the use of timers or timed delays. Normally these are counted in units of seconds. By setting the environment
variable "TEST_QUICK_TIMERS" to some true value, these timers run 10 times quicker, being measured in units of 0.1 seconds instead. This
value may be useful when running the tests interactively, to avoid them taking too long. The slower timers are preferred on automated
smoke-testing machines, to help guard against false negatives reported simply because of scheduling delays or high system load while
testing.
TEST_QUICK_TIMERS=1 ./Build test
FUNCTIONS
run_tests( $class, @tests )
Runs a test or collection of tests against the loop subclass given. The class being tested is loaded by this function; the containing
script does not need to "require" or "use" it first.
This function runs "Test::More::plan" to output its expected test count; the containing script should not do this.
TEST SUITES
The following test suite names exist, to be passed as a name in the @tests argument to "run_tests":
io
Tests the Loop's ability to watch filehandles for IO readiness
timer
Tests the Loop's ability to handle timer events
signal
Tests the Loop's ability to watch POSIX signals
idle
Tests the Loop's support for idle handlers
child
Tests the Loop's support for watching child processes by PID
control
Tests that the "run", "stop", "loop_once" and "loop_forever" methods behave correctly
AUTHOR
Paul Evans <leonerd@leonerd.org.uk>
perl v5.14.2 2012-10-24 IO::Async::LoopTests(3pm)
Check Out this Related Man Page
AnyEvent::Impl::IOAsync(3pm) User Contributed Perl Documentation AnyEvent::Impl::IOAsync(3pm)NAME
AnyEvent::Impl::IOAsync - AnyEvent adaptor for IO::Async
SYNOPSIS
use AnyEvent;
use IO::Async::Loop;
# optionally set another event loop
use AnyEvent::Impl::IOAsync;
my $loop = new IO::Async::Loop;
AnyEvent::Impl::IOAsync::set_loop $loop;
DESCRIPTION
This module provides support for IO::Async as AnyEvent backend. It supports I/O, timers, signals and child process watchers. Idle watchers
are emulated. I/O watchers need to dup their fh because IO::Async only supports IO handles, not plain file descriptors.
PROBLEMS WITH IO ::Async
This section had a long list of problems and shortcomings that made it almost impossible to support IO::Async. With version 0.33 of
IO::Async, however, most of these have been fixed, so IO::Async can now be used as easily as many other loops.
There are a few remaining problems that require emulation or workarounds:
No support for multiple watchers per event
In most (all? documentation?) cases you cannot have multiple watchers for the same event (what's the point of having all these fancy
notifier classes when you cannot have multiple notifiers for the same event? That's like only allowing one timer per second or so...).
For I/O watchers, AnyEvent has to dup() every file handle, as IO::Async fails to support the same or different file handles pointing to
the same fd (the good thing is that it is documented, but why not fix it instead?).
Apart from these fatal flaws, there are a number of unpleasent properties that just need some mentioning:
Confusing and misleading names
Another rather negative point about this module family is its name, which is deeply confusing: Despite the "async" in the name,
IO::Async only does synchronous I/O, there is nothing "asynchronous" about it whatsoever (when I first heard about it, I thought, "wow,
a second async I/O module, what does it do compared to IO::AIO", and was somehow set back when I learned that the only "async" aspect
of it is the name).
Inconsistent, incomplete and convoluted API
Implementing AnyEvent's rather simple timers on top of IO::Async's timers was a nightmare (try implementing a timer with configurable
interval and delay value...).
The method naming is chaotic: "watch_child" creates a child watcher, but "watch_io" is an internal method; "detach_signal" removes a
signal watcher, but "detach_child" forks a subprocess and so on).
Unpleasant surprises on GNU/Linux
When you develop your program on FreeBSD and run it on GNU/Linux, you might have unpleasant surprises, as IO::Async::Loop will by
default use IO::Async::Loop::Epoll, which is incompatible with "fork", so your network server will run into spurious and very hard to
debug problems under heavy load, as IO::Async forks a lot of processes, e.g. for DNS resolution. It would be better if IO::Async would
only load "safe" backends by default (or fix the epoll backend to work in the presence of fork, which admittedly is hard - EV does it
for you, and also does not use unsafe backends by default).
On the positive side, performance with IO::Async is quite good even in my very demanding eyes.
SEE ALSO
AnyEvent, IO::Async.
AUTHOR
Marc Lehmann <schmorp@schmorp.de>
http://anyevent.schmorp.de
Paul Evans <leonerd@leonerd.org.uk>
Rewrote the backend for IO::Async version 0.33.
perl v5.14.2 2012-04-08 AnyEvent::Impl::IOAsync(3pm)