| … | |
… | |
| 237 | |
237 | |
| 238 | Although the callback might get passed parameters, their value and |
238 | Although the callback might get passed parameters, their value and |
| 239 | presence is undefined and you cannot rely on them. Portable AnyEvent |
239 | presence is undefined and you cannot rely on them. Portable AnyEvent |
| 240 | callbacks cannot use arguments passed to signal watcher callbacks. |
240 | callbacks cannot use arguments passed to signal watcher callbacks. |
| 241 | |
241 | |
| 242 | Multiple signal occurances can be clumped together into one callback |
242 | Multiple signal occurrences can be clumped together into one callback |
| 243 | invocation, and callback invocation will be synchronous. synchronous means |
243 | invocation, and callback invocation will be synchronous. Synchronous means |
| 244 | that it might take a while until the signal gets handled by the process, |
244 | that it might take a while until the signal gets handled by the process, |
| 245 | but it is guarenteed not to interrupt any other callbacks. |
245 | but it is guaranteed not to interrupt any other callbacks. |
| 246 | |
246 | |
| 247 | The main advantage of using these watchers is that you can share a signal |
247 | The main advantage of using these watchers is that you can share a signal |
| 248 | between multiple watchers. |
248 | between multiple watchers. |
| 249 | |
249 | |
| 250 | This watcher might use C<%SIG>, so programs overwriting those signals |
250 | This watcher might use C<%SIG>, so programs overwriting those signals |
| … | |
… | |
| 310 | Condition variables can be created by calling the C<< AnyEvent->condvar |
310 | Condition variables can be created by calling the C<< AnyEvent->condvar |
| 311 | >> method, usually without arguments. The only argument pair allowed is |
311 | >> method, usually without arguments. The only argument pair allowed is |
| 312 | C<cb>, which specifies a callback to be called when the condition variable |
312 | C<cb>, which specifies a callback to be called when the condition variable |
| 313 | becomes true. |
313 | becomes true. |
| 314 | |
314 | |
| 315 | After creation, the conditon variable is "false" until it becomes "true" |
315 | After creation, the condition variable is "false" until it becomes "true" |
| 316 | by calling the C<send> method. |
316 | by calling the C<send> method. |
| 317 | |
317 | |
| 318 | Condition variables are similar to callbacks, except that you can |
318 | Condition variables are similar to callbacks, except that you can |
| 319 | optionally wait for them. They can also be called merge points - points |
319 | optionally wait for them. They can also be called merge points - points |
| 320 | in time where multiple outstandign events have been processed. And yet |
320 | in time where multiple outstanding events have been processed. And yet |
| 321 | another way to call them is transations - each condition variable can be |
321 | another way to call them is transactions - each condition variable can be |
| 322 | used to represent a transaction, which finishes at some point and delivers |
322 | used to represent a transaction, which finishes at some point and delivers |
| 323 | a result. |
323 | a result. |
| 324 | |
324 | |
| 325 | Condition variables are very useful to signal that something has finished, |
325 | Condition variables are very useful to signal that something has finished, |
| 326 | for example, if you write a module that does asynchronous http requests, |
326 | for example, if you write a module that does asynchronous http requests, |
| … | |
… | |
| 332 | you can block your main program until an event occurs - for example, you |
332 | you can block your main program until an event occurs - for example, you |
| 333 | could C<< ->recv >> in your main program until the user clicks the Quit |
333 | could C<< ->recv >> in your main program until the user clicks the Quit |
| 334 | button of your app, which would C<< ->send >> the "quit" event. |
334 | button of your app, which would C<< ->send >> the "quit" event. |
| 335 | |
335 | |
| 336 | Note that condition variables recurse into the event loop - if you have |
336 | Note that condition variables recurse into the event loop - if you have |
| 337 | two pieces of code that call C<< ->recv >> in a round-robbin fashion, you |
337 | two pieces of code that call C<< ->recv >> in a round-robin fashion, you |
| 338 | lose. Therefore, condition variables are good to export to your caller, but |
338 | lose. Therefore, condition variables are good to export to your caller, but |
| 339 | you should avoid making a blocking wait yourself, at least in callbacks, |
339 | you should avoid making a blocking wait yourself, at least in callbacks, |
| 340 | as this asks for trouble. |
340 | as this asks for trouble. |
| 341 | |
341 | |
| 342 | Condition variables are represented by hash refs in perl, and the keys |
342 | Condition variables are represented by hash refs in perl, and the keys |
| … | |
… | |
| 443 | doesn't execute once). |
443 | doesn't execute once). |
| 444 | |
444 | |
| 445 | This is the general pattern when you "fan out" into multiple subrequests: |
445 | This is the general pattern when you "fan out" into multiple subrequests: |
| 446 | use an outer C<begin>/C<end> pair to set the callback and ensure C<end> |
446 | use an outer C<begin>/C<end> pair to set the callback and ensure C<end> |
| 447 | is called at least once, and then, for each subrequest you start, call |
447 | is called at least once, and then, for each subrequest you start, call |
| 448 | C<begin> and for eahc subrequest you finish, call C<end>. |
448 | C<begin> and for each subrequest you finish, call C<end>. |
| 449 | |
449 | |
| 450 | =back |
450 | =back |
| 451 | |
451 | |
| 452 | =head3 METHODS FOR CONSUMERS |
452 | =head3 METHODS FOR CONSUMERS |
| 453 | |
453 | |
| … | |
… | |
| 475 | (programs might want to do that to stay interactive), so I<if you are |
475 | (programs might want to do that to stay interactive), so I<if you are |
| 476 | using this from a module, never require a blocking wait>, but let the |
476 | using this from a module, never require a blocking wait>, but let the |
| 477 | caller decide whether the call will block or not (for example, by coupling |
477 | caller decide whether the call will block or not (for example, by coupling |
| 478 | condition variables with some kind of request results and supporting |
478 | condition variables with some kind of request results and supporting |
| 479 | callbacks so the caller knows that getting the result will not block, |
479 | callbacks so the caller knows that getting the result will not block, |
| 480 | while still suppporting blocking waits if the caller so desires). |
480 | while still supporting blocking waits if the caller so desires). |
| 481 | |
481 | |
| 482 | Another reason I<never> to C<< ->recv >> in a module is that you cannot |
482 | Another reason I<never> to C<< ->recv >> in a module is that you cannot |
| 483 | sensibly have two C<< ->recv >>'s in parallel, as that would require |
483 | sensibly have two C<< ->recv >>'s in parallel, as that would require |
| 484 | multiple interpreters or coroutines/threads, none of which C<AnyEvent> |
484 | multiple interpreters or coroutines/threads, none of which C<AnyEvent> |
| 485 | can supply. |
485 | can supply. |
| … | |
… | |
| 1481 | speed most when you have lots of watchers, not when you only have a few of |
1481 | speed most when you have lots of watchers, not when you only have a few of |
| 1482 | them). |
1482 | them). |
| 1483 | |
1483 | |
| 1484 | EV is again fastest. |
1484 | EV is again fastest. |
| 1485 | |
1485 | |
| 1486 | Perl again comes second. It is noticably faster than the C-based event |
1486 | Perl again comes second. It is noticeably faster than the C-based event |
| 1487 | loops Event and Glib, although the difference is too small to really |
1487 | loops Event and Glib, although the difference is too small to really |
| 1488 | matter. |
1488 | matter. |
| 1489 | |
1489 | |
| 1490 | POE also performs much better in this case, but is is still far behind the |
1490 | POE also performs much better in this case, but is is still far behind the |
| 1491 | others. |
1491 | others. |
