1AnyEvent::Impl::IOAsyncU(s3e)r Contributed Perl DocumentaAtniyoEnvent::Impl::IOAsync(3)
2
3
4

NAME

6       AnyEvent::Impl::IOAsync - AnyEvent adaptor for IO::Async
7

SYNOPSIS

9         use AnyEvent;
10         use IO::Async::Loop;
11
12         # optionally set another event loop
13         use AnyEvent::Impl::IOAsync;
14         my $loop = new IO::Async::Loop;
15         AnyEvent::Impl::IOAsync::set_loop $loop;
16

DESCRIPTION

18       This module provides support for IO::Async as AnyEvent backend. It
19       supports I/O, timers, signals and child process watchers. Idle watchers
20       are emulated.  I/O watchers need to dup their fh because IO::Async only
21       supports IO handles, not plain file descriptors.
22

FUNCTIONS AND VARIABLES

24       The only user-servicible part in this module is the "set_loop" function
25       and $LOOP variable:
26
27       AnyEvent::Impl::IOAsync::set_loop $new_loop
28           Unfortunately, IO::Async has no concept of a default loop. Modules
29           using IO::Async must be told by their caller which loop to use,
30           which makes it impossible to transparently use IO::Async from a
31           module.
32
33           This module is no exception. It creates a new IO::Async::Loop
34           object when it is loaded. This might not be the right loop object,
35           though, and thus you can replace it by a call to this function with
36           the loop object of your choice.
37
38           Note that switching loops while watchers are already initialised
39           can have unexpected effects, and is not supported unless you can
40           live witht he consequences.
41
42       $AnyEvent::Impl::IOAsync::LOOP
43           This variable always contains the IO::Async::Loop object used by
44           this AnyEvent backend. See above for more info.
45
46           Storing the "default" loop makes this module a possible arbiter for
47           other modules that want to use IO::Async transparently. It's
48           advised to directly refer to this variable each time you want to
49           use it, without making a local copy.
50

PROBLEMS WITH IO::Async

52       This section had a long list of problems and shortcomings that made it
53       almost impossible to support IO::Async. With version 0.33 of IO::Async,
54       however, most of these have been fixed, so IO::Async can now be used as
55       easily as many other loops.
56
57       There are a few remaining problems that require emulation or
58       workarounds:
59
60       No support for multiple watchers per event
61           In most (all? documentation?) cases you cannot have multiple
62           watchers for the same event (what's the point of having all these
63           fancy notifier classes when you cannot have multiple notifiers for
64           the same event? That's like only allowing one timer per second or
65           so...).
66
67           For I/O watchers, AnyEvent has to dup() every file handle, as
68           IO::Async fails to support the same or different file handles
69           pointing to the same fd (the good thing is that it is documented,
70           but why not fix it instead?).
71
72       Apart from these fatal flaws, there are a number of unpleasent
73       properties that just need some mentioning:
74
75       Confusing and misleading names
76           Another rather negative point about this module family is its name,
77           which is deeply confusing: Despite the "async" in the name,
78           IO::Async only does synchronous I/O, there is nothing
79           "asynchronous" about it whatsoever (when I first heard about it, I
80           thought, "wow, a second async I/O module, what does it do compared
81           to IO::AIO", and was somehow set back when I learned that the only
82           "async" aspect of it is the name).
83
84       Inconsistent, incomplete and convoluted API
85           Implementing AnyEvent's rather simple timers on top of IO::Async's
86           timers was a nightmare (try implementing a timer with configurable
87           interval and delay value...).
88
89           The method naming is chaotic: "watch_child" creates a child
90           watcher, but "watch_io" is an internal method; "detach_signal"
91           removes a signal watcher, but "detach_child" forks a subprocess and
92           so on).
93
94       Unpleasant surprises on GNU/Linux
95           When you develop your program on FreeBSD and run it on GNU/Linux,
96           you might have unpleasant surprises, as IO::Async::Loop will by
97           default use IO::Async::Loop::Epoll, which is incompatible with
98           "fork", so your network server will run into spurious and very hard
99           to debug problems under heavy load, as IO::Async forks a lot of
100           processes, e.g. for DNS resolution. It would be better if IO::Async
101           would only load "safe" backends by default (or fix the epoll
102           backend to work in the presence of fork, which admittedly is hard -
103           EV does it for you, and also does not use unsafe backends by
104           default).
105
106       On the positive side, performance with IO::Async is quite good even in
107       my very demanding eyes.
108

SEE ALSO

110       AnyEvent, IO::Async.
111

AUTHOR

113        Marc Lehmann <schmorp@schmorp.de>
114        http://anyevent.schmorp.de
115
116        Paul Evans <leonerd@leonerd.org.uk>
117        Rewrote the backend for IO::Async version 0.33.
118
119
120
121perl v5.30.1                      2020-01-29        AnyEvent::Impl::IOAsync(3)
Impressum