| … | |
… | |
| 124 | forgetting about the watcher, for example, by C<undef>'ing the variable it |
124 | forgetting about the watcher, for example, by C<undef>'ing the variable it |
| 125 | is stored in. AnyEvent will automatically clean up the watcher if it is no |
125 | is stored in. AnyEvent will automatically clean up the watcher if it is no |
| 126 | longer used, much like Perl closes your file handles if you no longer use |
126 | longer used, much like Perl closes your file handles if you no longer use |
| 127 | them anywhere. |
127 | them anywhere. |
| 128 | |
128 | |
|
|
129 | =head3 A short note on callbacks |
|
|
130 | |
|
|
131 | A common issue that hits people is the problem of passing parameters |
|
|
132 | to callbacks. Programmers used to languages such as C or C++ are often |
|
|
133 | used to a style where one passes the address of a function (a function |
|
|
134 | reference) and some data value, e.g.: |
|
|
135 | |
|
|
136 | sub callback { |
|
|
137 | my ($arg) = @_; |
|
|
138 | |
|
|
139 | $arg->method; |
|
|
140 | } |
|
|
141 | |
|
|
142 | my $arg = ...; |
|
|
143 | |
|
|
144 | call_me_back_later \&callback, $arg; |
|
|
145 | |
|
|
146 | This is clumsy, as the place where behaviour is specified (when the |
|
|
147 | callback is registered) is often far away from the place where behaviour |
|
|
148 | is implemented. It also doesn't use Perl syntax to invoke the code. There |
|
|
149 | is also an abstraction penalty to pay as one has to I<name> the callback, |
|
|
150 | which often is unnecessary and leads to nonsensical or duplicated names. |
|
|
151 | |
|
|
152 | In Perl, one can specify behaviour much more directly by using |
|
|
153 | I<closures>. Closures are code blocks that take a reference to the |
|
|
154 | enclosing scope(s) when they are created. This means lexical variables in scope at the time |
|
|
155 | of creating the closure can simply be used inside the closure: |
|
|
156 | |
|
|
157 | my $arg = ...; |
|
|
158 | |
|
|
159 | call_me_back_later sub { $arg->method }; |
|
|
160 | |
|
|
161 | Under most circumstances, closures are faster, use less resources and |
|
|
162 | result in much clearer code then the traditional approach. Faster, |
|
|
163 | because parameter passing and storing them in local variables in Perl |
|
|
164 | is relatively slow. Less resources, because closures take references to |
|
|
165 | existing variables without having to create new ones, and clearer code |
|
|
166 | because it is immediately obvious that the second example calls the |
|
|
167 | C<method> method when the callback is invoked. |
|
|
168 | |
|
|
169 | Apart from these, the strongest argument for using closures with AnyEvent |
|
|
170 | is that AnyEvent does not allow passing parameters to the callback, so |
|
|
171 | closures are the only way to achieve that in most cases :-> |
|
|
172 | |
|
|
173 | |
| 129 | =head2 Condition Variables |
174 | =head2 Condition Variables |
| 130 | |
175 | |
| 131 | However, the above is not a fully working program, and will not work |
176 | Back to the I/O watcher example: The code not yet a fully working program, |
| 132 | as-is. The reason is that your callback will not be invoked out of the |
177 | and will not work as-is. The reason is that your callback will not be |
| 133 | blue, you have to run the event loop. Also, event-based programs sometimes |
178 | invoked out of the blue, you have to run the event loop. Also, event-based |
| 134 | have to block, too, as when there simply is nothing else to do and |
179 | programs sometimes have to block, too, as when there simply is nothing |
| 135 | everything waits for some events, it needs to block the process as well. |
180 | else to do and everything waits for some events, it needs to block the |
|
|
181 | process as well. |
| 136 | |
182 | |
| 137 | In AnyEvent, this is done using condition variables. Condition variables |
183 | In AnyEvent, this is done using condition variables. Condition variables |
| 138 | are named "condition variables" because they represent a condition that is |
184 | are named "condition variables" because they represent a condition that is |
| 139 | initially false and needs to be fulfilled. |
185 | initially false and needs to be fulfilled. |
| 140 | |
186 | |
| … | |
… | |
| 142 | or even callbacks and many other things (and they are often called like |
188 | or even callbacks and many other things (and they are often called like |
| 143 | this in other frameworks). The important point is that you can create them |
189 | this in other frameworks). The important point is that you can create them |
| 144 | freely and later wait for them to become true. |
190 | freely and later wait for them to become true. |
| 145 | |
191 | |
| 146 | Condition variables have two sides - one side is the "producer" of the |
192 | Condition variables have two sides - one side is the "producer" of the |
| 147 | condition (whatever code detects the condition), the other side is the |
193 | condition (whatever code detects and flags the condition), the other side |
| 148 | "consumer" (the code that waits for that condition). |
194 | is the "consumer" (the code that waits for that condition). |
| 149 | |
195 | |
| 150 | In our example in the previous section, the producer is the event callback |
196 | In our example in the previous section, the producer is the event callback |
| 151 | and there is no consumer yet - let's change that now: |
197 | and there is no consumer yet - let's change that right now: |
| 152 | |
198 | |
| 153 | use AnyEvent; |
199 | use AnyEvent; |
| 154 | |
200 | |
| 155 | $| = 1; print "enter your name> "; |
201 | $| = 1; print "enter your name> "; |
| 156 | |
202 | |
