… | |
… | |
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. |