1AnyEvent::FAQ(3)      User Contributed Perl Documentation     AnyEvent::FAQ(3)
2
3
4

NAME

6       AnyEvent::FAQ - frequently asked questions
7

FAQs

9       The newest version of this document can be found at
10       <http://pod.tst.eu/http://cvs.schmorp.de/AnyEvent/lib/AnyEvent/FAQ.pod>.
11
12   My program exits before doing anything, what's going on?
13       Programmers new to event-based programming often forget that you can
14       actually do other stuff while "waiting" for an event to occur and
15       therefore forget to actually wait when they do not, in fact, have
16       anything else to do.
17
18       Here is an example:
19
20          use AnyEvent;
21
22          my $timer = AnyEvent->timer (after => 5, cb => sub { say "hi" });
23
24       The expectation might be for the program to print "hi" after 5 seconds
25       and then probably to exit. However, if you run this, your program will
26       exit almost instantly: Creating the timer does not wait for it, instead
27       the "timer" method returns immediately and perl executes the rest of
28       the program. But there is nothing left to execute, so perl exits.
29
30       To force AnyEvent to wait for something, use a condvar:
31
32          use AnyEvent;
33
34          my $quit_program = AnyEvent->condvar;
35          my $timer = AnyEvent->timer (after => 5, cb => sub { $quit_program->send });
36
37          $quit_program->recv;
38
39       Here the program doesn't immediately exit, because it first waits for
40       the "quit_program" condition.
41
42       In most cases, your main program should call the event library "loop"
43       function directly:
44
45          use EV;
46          use AnyEvent;
47
48          ...
49
50          EV::loop;
51
52   Why is my "tcp_connect" callback never called?
53       Tricky: "tcp_connect" (and a few other functions in AnyEvent::Socket)
54       is critically sensitive to the caller context.
55
56       In void context, it will just do its thing and eventually call the
57       callback. In any other context, however, it will return a special
58       "guard" object - when it is destroyed (e.g. when you don't store it but
59       throw it away), tcp_connect will no longer try to connect or call any
60       callbacks.
61
62       Often this happens when the "tcp_connect" call is at the end of a
63       function:
64
65          sub do_connect {
66             tcp_connect "www.example.com", 80, sub {
67                ... lengthy code
68             };
69          }
70
71       Then the caller decides whether there is a void context or not. One can
72       avoid these cases by explicitly returning nothing:
73
74          sub do_connect {
75             tcp_connect "www.example.com", 80, sub {
76                ... lengthy code
77             };
78
79             () # return nothing
80          }
81
82   Why do some backends use a lot of CPU in "AE::cv->recv"?
83       Many people try out this simple program, or its equivalent:
84
85          use AnyEvent;
86          AnyEvent->condvar->recv;
87
88       They are then shocked to see that this basically idles with the Perl
89       backend, but uses 100% CPU with the EV backend, which is supposed to be
90       sooo efficient.
91
92       The key to understand this is to understand that the above program is
93       actually buggy: Nothing calls "->send" on the condvar, ever. Worse,
94       there are no event watchers whatsoever. Basically, it creates a
95       deadlock: there is no way to make progress, this program doesn't do
96       anything useful, and this will not change in the future: it is already
97       an ex-parrot.
98
99       Some backends react to this by freezing, some by idling, and some do a
100       100% CPU loop.
101
102       Since this program is not useful (and behaves as documented with all
103       backends, as AnyEvent makes no CPU time guarantees), this shouldn't be
104       a big deal: as soon as your program actually implements something, the
105       CPU usage will be normal.
106
107   Why does this FAQ not deal with AnyEvent::Handle questions?
108       Because AnyEvent::Handle has a NONFAQ on its own that already deals
109       with common issues.
110
111   How can I combine Win32::GUI applications with AnyEvent?
112       Well, not in the same OS thread, that's for sure :) What you can do is
113       create another ithread (or fork) and run AnyEvent inside that thread,
114       or better yet, run all your GUI code in a second ithread.
115
116       For example, you could load Win32::GUI and AnyEvent::Util, then create
117       a portable socketpair for GUI->AnyEvent communication.
118
119       Then fork/create a new ithread, in there, create a Window and send the
120       "$WINDOW->{-Handle}" to the AnyEvent ithread so it can "PostMessage".
121
122       GUI to AnyEvent communication could work by pushing some data into a
123       Thread::Queue and writing a byte into the socket. The AnyEvent watcher
124       on the other side will then look at the queue.
125
126       AnyEvent to GUI communications can also use a Thread::Queue, but to
127       wake up the GUI thread, it would instead use "Win32::GUI::PostMessage
128       $WINDOW, 1030, 0, """, and the GUI thread would listen for these
129       messages by using "$WINDOW->Hook (1030 (), sub { ... })".
130
131   My callback dies and...
132       It must not - part of the contract betwene AnyEvent and user code is
133       that callbacks do not throw exceptions (and don't do even more evil
134       things, such as using "last" outside a loop :). If your callback might
135       die sometimes, you need to use "eval".
136
137       If you want to track down such a case and you can reproduce it, you can
138       enable wrapping (by calling "AnyEvent::Debug::wrap" or by setting
139       "PERL_ANYEVENT_DEBUG_WRAP=1" before starting your program). This will
140       wrap every callback into an eval and will report any exception complete
141       with a backtrace and some information about which watcher died, where
142       it was created and so on.
143

Author

145       Marc Lehmann <schmorp@schmorp.de>.
146
147
148
149perl v5.32.0                      2020-07-28                  AnyEvent::FAQ(3)
Impressum