… | |
… | |
303 | "cb", which specifies a callback to be called when the condition |
303 | "cb", which specifies a callback to be called when the condition |
304 | variable becomes true. |
304 | variable becomes true. |
305 | |
305 | |
306 | After creation, the condition variable is "false" until it becomes |
306 | After creation, the condition variable is "false" until it becomes |
307 | "true" by calling the "send" method (or calling the condition variable |
307 | "true" by calling the "send" method (or calling the condition variable |
308 | as if it were a callback). |
308 | as if it were a callback, read about the caveats in the description for |
|
|
309 | the "->send" method). |
309 | |
310 | |
310 | Condition variables are similar to callbacks, except that you can |
311 | Condition variables are similar to callbacks, except that you can |
311 | optionally wait for them. They can also be called merge points - points |
312 | optionally wait for them. They can also be called merge points - points |
312 | in time where multiple outstanding events have been processed. And yet |
313 | in time where multiple outstanding events have been processed. And yet |
313 | another way to call them is transactions - each condition variable can |
314 | another way to call them is transactions - each condition variable can |
… | |
… | |
383 | Any arguments passed to the "send" call will be returned by all |
384 | Any arguments passed to the "send" call will be returned by all |
384 | future "->recv" calls. |
385 | future "->recv" calls. |
385 | |
386 | |
386 | Condition variables are overloaded so one can call them directly (as |
387 | Condition variables are overloaded so one can call them directly (as |
387 | a code reference). Calling them directly is the same as calling |
388 | a code reference). Calling them directly is the same as calling |
388 | "send". |
389 | "send". Note, however, that many C-based event loops do not handle |
|
|
390 | overloading, so as tempting as it may be, passing a condition |
|
|
391 | variable instead of a callback does not work. Both the pure perl and |
|
|
392 | EV loops support overloading, however, as well as all functions that |
|
|
393 | use perl to invoke a callback (as in AnyEvent::Socket and |
|
|
394 | AnyEvent::DNS for example). |
389 | |
395 | |
390 | $cv->croak ($error) |
396 | $cv->croak ($error) |
391 | Similar to send, but causes all call's to "->recv" to invoke |
397 | Similar to send, but causes all call's to "->recv" to invoke |
392 | "Carp::croak" with the given error message/object/scalar. |
398 | "Carp::croak" with the given error message/object/scalar. |
393 | |
399 | |
… | |
… | |
578 | If it doesn't care, it can just "use AnyEvent" and use it itself, or not |
584 | If it doesn't care, it can just "use AnyEvent" and use it itself, or not |
579 | do anything special (it does not need to be event-based) and let |
585 | do anything special (it does not need to be event-based) and let |
580 | AnyEvent decide which implementation to chose if some module relies on |
586 | AnyEvent decide which implementation to chose if some module relies on |
581 | it. |
587 | it. |
582 | |
588 | |
583 | If the main program relies on a specific event model. For example, in |
589 | If the main program relies on a specific event model - for example, in |
584 | Gtk2 programs you have to rely on the Glib module. You should load the |
590 | Gtk2 programs you have to rely on the Glib module - you should load the |
585 | event module before loading AnyEvent or any module that uses it: |
591 | event module before loading AnyEvent or any module that uses it: |
586 | generally speaking, you should load it as early as possible. The reason |
592 | generally speaking, you should load it as early as possible. The reason |
587 | is that modules might create watchers when they are loaded, and AnyEvent |
593 | is that modules might create watchers when they are loaded, and AnyEvent |
588 | will decide on the event model to use as soon as it creates watchers, |
594 | will decide on the event model to use as soon as it creates watchers, |
589 | and it might chose the wrong one unless you load the correct one |
595 | and it might chose the wrong one unless you load the correct one |
590 | yourself. |
596 | yourself. |
591 | |
597 | |
592 | You can chose to use a rather inefficient pure-perl implementation by |
598 | You can chose to use a pure-perl implementation by loading the |
593 | loading the "AnyEvent::Impl::Perl" module, which gives you similar |
599 | "AnyEvent::Impl::Perl" module, which gives you similar behaviour |
594 | behaviour everywhere, but letting AnyEvent chose is generally better. |
600 | everywhere, but letting AnyEvent chose the model is generally better. |
|
|
601 | |
|
|
602 | MAINLOOP EMULATION |
|
|
603 | Sometimes (often for short test scripts, or even standalone programs who |
|
|
604 | only want to use AnyEvent), you do not want to run a specific event |
|
|
605 | loop. |
|
|
606 | |
|
|
607 | In that case, you can use a condition variable like this: |
|
|
608 | |
|
|
609 | AnyEvent->condvar->recv; |
|
|
610 | |
|
|
611 | This has the effect of entering the event loop and looping forever. |
|
|
612 | |
|
|
613 | Note that usually your program has some exit condition, in which case it |
|
|
614 | is better to use the "traditional" approach of storing a condition |
|
|
615 | variable somewhere, waiting for it, and sending it when the program |
|
|
616 | should exit cleanly. |
595 | |
617 | |
596 | OTHER MODULES |
618 | OTHER MODULES |
597 | The following is a non-exhaustive list of additional modules that use |
619 | The following is a non-exhaustive list of additional modules that use |
598 | AnyEvent and can therefore be mixed easily with other AnyEvent modules |
620 | AnyEvent and can therefore be mixed easily with other AnyEvent modules |
599 | in the same program. Some of the modules come with AnyEvent, some are |
621 | in the same program. Some of the modules come with AnyEvent, some are |
… | |
… | |
612 | Provides various utility functions for (internet protocol) sockets, |
634 | Provides various utility functions for (internet protocol) sockets, |
613 | addresses and name resolution. Also functions to create non-blocking |
635 | addresses and name resolution. Also functions to create non-blocking |
614 | tcp connections or tcp servers, with IPv6 and SRV record support and |
636 | tcp connections or tcp servers, with IPv6 and SRV record support and |
615 | more. |
637 | more. |
616 | |
638 | |
|
|
639 | AnyEvent::DNS |
|
|
640 | Provides rich asynchronous DNS resolver capabilities. |
|
|
641 | |
617 | AnyEvent::HTTPD |
642 | AnyEvent::HTTPD |
618 | Provides a simple web application server framework. |
643 | Provides a simple web application server framework. |
619 | |
|
|
620 | AnyEvent::DNS |
|
|
621 | Provides rich asynchronous DNS resolver capabilities. |
|
|
622 | |
644 | |
623 | AnyEvent::FastPing |
645 | AnyEvent::FastPing |
624 | The fastest ping in the west. |
646 | The fastest ping in the west. |
625 | |
647 | |
626 | Net::IRC3 |
648 | Net::IRC3 |