1AnyEvent::Impl::IOAsyncU(s3e)r Contributed Perl DocumentaAtniyoEnvent::Impl::IOAsync(3)
2
6 AnyEvent::Impl::IOAsync - AnyEvent adaptor for IO::Async
7
9 use AnyEvent;
10 use IO::ASync::Loop;
12 use AnyEvent::Impl::IOAsync;
13 my $loop = new IO::Async::Loop;
15 AnyEvent::Impl::IOAsync::set_loop $loop;
17
19 This module provides support for IO::Async as AnyEvent backend. Due to
20 the rather sad state of IO::Async, support is only available partially
21 (only timers and I/O watchers are supported, signals and child watchers
22 are emulated by AnyEvent itself (fighting with IO::Async, so you cannot
23 use both), idle watchers are being emulated, I/O watchers need to dup
24 their fh.
25
27 There have been multiple attempts at providing an AnyEvent interface to
28 IO::Async, and the effort is ongoing. Supporting IO::Async is hard.
29 Here's why:
30 IO::Async integration cannot be automatic - no default loop
32 IO::Async doesn't offer an interface suitable for independent usage
33 of event sources: there is no standard way to share the main event
34 loop between modules - modules have to somehow agree on how to do
35 this.
36 For AnyEvent to work with IO::Async, the IO::Async main program has
38 to call "AnyEvent::Impl::IOAsync::set_loop" with the
39 "IO::Async::Loop" object that AnyEvent is to use, see the SYNOPSIS
40 section for an example.
41 It is possible to get a copy of the loop by reading
43 $AnyEvent::Impl::IOAsync::LOOP, so AnyEvent could be used as a
44 central place to store the default IO::Async::Loop object, also for
45 other modules, if there is any need for that.
46 Broken child watchers
48 IO::Async is the only module that requires you to call a special
49 function before even forking your child program, while the AnyEvent
50 API itself (which works with other event loops) works as long as it
51 has been initialised (AnyEvent's own pure perl implementation
52 doesn't even suffer from these limitations and just works).
53 Worse, IO::Async does not let you install multiple child watchers,
55 does not let you watch for any child, and apparently an interface
56 to unregister child watchers has been forgotten as well.
57 As a result, AnyEvent::Impl::IOAsync has to fall back on it's own
59 child management, which makes it impossible to watch for child
60 processes via both AnyEvent and IO::Async. Hooking and Patching
61 IO::Async has been considered, but is considerable work.
62 No support for multiple watchers per event
64 In most (all? documentation?) cases you cannot have multiple
65 watchers for the same event (what's the point of having all these
66 fancy notifier classes when you cannot have multiple notifiers for
67 the same event? That's like only allowing one timer per second or
68 so...).
69 This makes signal watchers almost useless (You could just hook them
71 yourself, you can't share any of them, as would make sense for e.g.
72 SIGTERM, SIGTSTP, SIGPWR, SIGUSR1 etc.).
73 As a result, AnyEvent falls back to it's own signal handling (it is
75 pointless to somehow share the IO::Async watcher, as it doesn't
76 matter if AnyEvent blocks the signal via IO::Async or directly, and
77 AnyEvents signal handling is race-free).
78 For I/O watchers, AnyEvent has to dup() every file handle, as
80 IO::Async fails to support the same or different file handles
81 pointing to the same fd (this is at least documented, but why not
82 fix it instead?).
83 Apart from these fatal flaws, there are a number of unpleasent
85 properties that just need some mentioning:
86 Confusing and misleading name
88 Another rather negative point about this module family is its name,
89 which is deeply confusing: Despite the "async" in the name,
90 IO::Async only does synchronous I/O, there is nothing
91 "asynchronous" about it whatsoever (when I first heard about it, I
92 thought, "wow, a second async I/O module, what does it do compared
93 to IO::AIO", and was somehow set back when I learned that the only
94 "async" aspect of it is the name).
95 Inconsistent, incomplete and convoluted API
97 Implementing AnyEvent's rather simple timers on top of IO::Async's
98 timers was a nightmare (try implementing a timer with configurable
99 interval and delay value...).
100 How to actually get I/O events in IO::Async::Handle is
102 undocumented: read events are apparently automatic, for write
103 events, you have to explicitly request "want_writeready", and
104 specifying "want_readready" is apparently a usage bug (it doesn't
105 exist). All this must be deduced from reading the sources.
106 You can't stop child watchers. Even reading the sources I found no
108 way to stop them. It must have been forgotten.
109 The method naming is chaotic: "watch_child" creates a child
111 watcher, but "watch_io" is an internal method; "detach_signal"
112 removes a signal watcher, but "detach_child" forks a subprocess and
113 so on).
114 IO::Async has weird checks - passing in a callable reference is
116 sometimes forbidden (of course, this is checked on every
117 invocation, not when the callback is registered, so you have no
118 idea where in your code you passed it in), as the code checks
119 explicitly for code references, disallowing callable objects.
120 Unpleasant surprises on GNU/Linux
122 When you develop your program on FreeBSD and run it on GNU/Linux,
123 you might have unpleasant surprises, as IO::Async::Loop will by
124 default use IO::Async::Loop::Epoll, which is incompatible with
125 "fork", so your network server will run into spurious and very hard
126 to debug problems under heavy load, as IO::Async forks a lot of
127 processes, e.g. for DNS resolution. It would be better if IO::Async
128 would only load "safe" backends by default (or fix the epoll
129 backend to work in the presence of fork, which admittedly is hard -
130 EV does it for you, and also does not use unsafe backends by
131 default).
132 Exiting considered harmful
134 (in cleanup) Can't call method "parent" on an undefined value
135 at IO/Async/Loop.pm line 297 during global destruction.
136 IO::Async just hates global destruction. Calling "exit" will easily
138 give you one such line per watcher.
139 The problem is that IO::Async::Loop is itself not warning-free, but
141 actually enables warnings for itself.
142 (Ok, the real bug is of course perl's broken mark & sweep garbage
144 collector that corrupts data structures).
145 On the positive side, performance with IO::Async is quite good even in
147 my very demanding eyes.
148
150 AnyEvent, EV.
151
153 Marc Lehmann <schmorp@schmorp.de>
154 http://home.schmorp.de/
155perl v5.12.1 2009-09-15 AnyEvent::Impl::IOAsync(3)