| … | |
… | |
| 58 | modules, you get an enourmous amount of code and strict rules you have |
58 | modules, you get an enourmous amount of code and strict rules you have |
| 59 | to follow. AnyEvent, on the other hand, is lean and to the point by only |
59 | to follow. AnyEvent, on the other hand, is lean and to the point by only |
| 60 | offering the functionality that is useful, in as thin as a wrapper as |
60 | offering the functionality that is useful, in as thin as a wrapper as |
| 61 | technically possible. |
61 | technically possible. |
| 62 | |
62 | |
| 63 | Of course, if you want lots of policy (this is arguably somewhat useful in |
63 | Of course, if you want lots of policy (this can arguably be somewhat |
| 64 | many cases) and you want your users to the one and only event model your |
64 | useful) and you want to force your users to use the one and only event |
| 65 | module forces on them, you should I<not> use this module. |
65 | model, you should I<not> use this module. |
| 66 | |
66 | |
| 67 | |
67 | |
| 68 | =head1 DESCRIPTION |
68 | =head1 DESCRIPTION |
| 69 | |
69 | |
| 70 | L<AnyEvent> provides an identical interface to multiple event loops. This |
70 | L<AnyEvent> provides an identical interface to multiple event loops. This |
| … | |
… | |
| 179 | =item $cv->wait |
179 | =item $cv->wait |
| 180 | |
180 | |
| 181 | Wait (blocking if necessary) until the C<< ->broadcast >> method has been |
181 | Wait (blocking if necessary) until the C<< ->broadcast >> method has been |
| 182 | called on c<$cv>, while servicing other watchers normally. |
182 | called on c<$cv>, while servicing other watchers normally. |
| 183 | |
183 | |
| 184 | Not all event models support a blocking wait - some die in that case, so |
|
|
| 185 | if you are using this from a module, never require a blocking wait, but |
|
|
| 186 | let the caller decide wether the call will block or not (for example, |
|
|
| 187 | by coupling condition variables with some kind of request results and |
|
|
| 188 | supporting callbacks so the caller knows that getting the result will not |
|
|
| 189 | block, while still suppporting blockign waits if the caller so desires). |
|
|
| 190 | |
|
|
| 191 | You can only wait once on a condition - additional calls will return |
184 | You can only wait once on a condition - additional calls will return |
| 192 | immediately. |
185 | immediately. |
|
|
186 | |
|
|
187 | Not all event models support a blocking wait - some die in that case |
|
|
188 | (programs might want to do that so they stay interactive), so I<if you |
|
|
189 | are using this from a module, never require a blocking wait>, but let the |
|
|
190 | caller decide wether the call will block or not (for example, by coupling |
|
|
191 | condition variables with some kind of request results and supporting |
|
|
192 | callbacks so the caller knows that getting the result will not block, |
|
|
193 | while still suppporting blocking waits if the caller so desires). |
|
|
194 | |
|
|
195 | Another reason I<never> to C<< ->wait >> in a module is that you cannot |
|
|
196 | sensibly have two C<< ->wait >>'s in parallel, as that would require |
|
|
197 | multiple interpreters or coroutines/threads, none of which C<AnyEvent> |
|
|
198 | can supply (the coroutine-aware backends C<Coro::EV> and C<Coro::Event> |
|
|
199 | explicitly support concurrent C<< ->wait >>'s from different coroutines, |
|
|
200 | however). |
| 193 | |
201 | |
| 194 | =item $cv->broadcast |
202 | =item $cv->broadcast |
| 195 | |
203 | |
| 196 | Flag the condition as ready - a running C<< ->wait >> and all further |
204 | Flag the condition as ready - a running C<< ->wait >> and all further |
| 197 | calls to C<wait> will return after this method has been called. If nobody |
205 | calls to C<wait> will return after this method has been called. If nobody |
