AnyEvent::Impl::IOAsynUser Contributed Perl DocumentAnyEvent::Impl::IOAsync(3)NAMEAnyEvent::Impl::IOAsync - AnyEvent adaptor for IO::Async
SYNOPSIS
use AnyEvent;
use IO::ASync::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. Due to
the rather sad state of IO::Async, support is only available partially
(only timers and I/O watchers are supported, signals and child watchers
are emulated by AnyEvent itself (fighting with IO::Async, so you cannot
use both), idle watchers are being emulated, I/O watchers need to dup
their fh.
PROBLEMS WITH IO::Async
There have been multiple attempts at providing an AnyEvent interface to
IO::Async, and the effort is ongoing. Supporting IO::Async is hard.
Here's why:
IO::Async integration cannot be automatic - no default loop
IO::Async doesn't offer an interface suitable for independent usage
of event sources: there is no standard way to share the main event
loop between modules - modules have to somehow agree on how to do
this.
For AnyEvent to work with IO::Async, the IO::Async main program has
to call "AnyEvent::Impl::IOAsync::set_loop" with the
"IO::Async::Loop" object that AnyEvent is to use, see the SYNOPSIS
section for an example.
It is possible to get a copy of the loop by reading
$AnyEvent::Impl::IOAsync::LOOP, so AnyEvent could be used as a
central place to store the default IO::Async::Loop object, also for
other modules, if there is any need for that.
Broken child watchers
IO::Async is the only module that requires you to call a special
function before even forking your child program, while the AnyEvent
API itself (which works with other event loops) works as long as it
has been initialised (AnyEvent's own pure perl implementation
doesn't even suffer from these limitations and just works).
Worse, IO::Async does not let you install multiple child watchers,
does not let you watch for any child, and apparently an interface
to unregister child watchers has been forgotten as well.
As a result, AnyEvent::Impl::IOAsync has to fall back on it's own
child management, which makes it impossible to watch for child
processes via both AnyEvent and IO::Async. Hooking and Patching
IO::Async has been considered, but is considerable work.
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...).
This makes signal watchers almost useless (You could just hook them
yourself, you can't share any of them, as would make sense for e.g.
SIGTERM, SIGTSTP, SIGPWR, SIGUSR1 etc.).
As a result, AnyEvent falls back to it's own signal handling (it is
pointless to somehow share the IO::Async watcher, as it doesn't
matter if AnyEvent blocks the signal via IO::Async or directly, and
AnyEvents signal handling is race-free).
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 (this is at least 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 name
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...).
How to actually get I/O events in IO::Async::Handle is
undocumented: read events are apparently automatic, for write
events, you have to explicitly request "want_writeready", and
specifying "want_readready" is apparently a usage bug (it doesn't
exist). All this must be deduced from reading the sources.
You can't stop child watchers. Even reading the sources I found no
way to stop them. It must have been forgotten.
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).
IO::Async has weird checks - passing in a callable reference is
sometimes forbidden (of course, this is checked on every
invocation, not when the callback is registered, so you have no
idea where in your code you passed it in), as the code checks
explicitly for code references, disallowing callable objects.
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).
Exiting considered harmful
(in cleanup) Can't call method "parent" on an undefined value
at IO/Async/Loop.pm line 297 during global destruction.
IO::Async just hates global destruction. Calling "exit" will easily
give you one such line per watcher.
The problem is that IO::Async::Loop is itself not warning-free, but
actually enables warnings for itself.
(Ok, the real bug is of course perl's broken mark & sweep garbage
collector that corrupts data structures).
On the positive side, performance with IO::Async is quite good even in
my very demanding eyes.
SEE ALSO
AnyEvent, EV.
AUTHOR
Marc Lehmann <schmorp@schmorp.de>
http://home.schmorp.de/
perl v5.14.2 2009-09-15 AnyEvent::Impl::IOAsync(3)
