1 | =head1 NAME |
1 | =head1 NAME |
2 | |
2 | |
3 | AnyEvent - provide framework for multiple event loops |
3 | AnyEvent - events independent of event loop implementation |
4 | |
4 | |
5 | EV, Event, Glib, Tk, Perl, Event::Lib, Qt and POE are various supported |
5 | EV, Event, Glib, Tk, Perl, Event::Lib, Qt and POE are various supported |
6 | event loops. |
6 | event loops. |
7 | |
7 | |
8 | =head1 SYNOPSIS |
8 | =head1 SYNOPSIS |
… | |
… | |
40 | =head1 INTRODUCTION/TUTORIAL |
40 | =head1 INTRODUCTION/TUTORIAL |
41 | |
41 | |
42 | This manpage is mainly a reference manual. If you are interested |
42 | This manpage is mainly a reference manual. If you are interested |
43 | in a tutorial or some gentle introduction, have a look at the |
43 | in a tutorial or some gentle introduction, have a look at the |
44 | L<AnyEvent::Intro> manpage. |
44 | L<AnyEvent::Intro> manpage. |
|
|
45 | |
|
|
46 | =head1 SUPPORT |
|
|
47 | |
|
|
48 | There is a mailinglist for discussing all things AnyEvent, and an IRC |
|
|
49 | channel, too. |
|
|
50 | |
|
|
51 | See the AnyEvent project page at the B<Schmorpforge Ta-Sa Software |
|
|
52 | Respository>, at L<http://anyevent.schmorp.de>, for more info. |
45 | |
53 | |
46 | =head1 WHY YOU SHOULD USE THIS MODULE (OR NOT) |
54 | =head1 WHY YOU SHOULD USE THIS MODULE (OR NOT) |
47 | |
55 | |
48 | Glib, POE, IO::Async, Event... CPAN offers event models by the dozen |
56 | Glib, POE, IO::Async, Event... CPAN offers event models by the dozen |
49 | nowadays. So what is different about AnyEvent? |
57 | nowadays. So what is different about AnyEvent? |
… | |
… | |
509 | Condition variables are similar to callbacks, except that you can |
517 | Condition variables are similar to callbacks, except that you can |
510 | optionally wait for them. They can also be called merge points - points |
518 | optionally wait for them. They can also be called merge points - points |
511 | in time where multiple outstanding events have been processed. And yet |
519 | in time where multiple outstanding events have been processed. And yet |
512 | another way to call them is transactions - each condition variable can be |
520 | another way to call them is transactions - each condition variable can be |
513 | used to represent a transaction, which finishes at some point and delivers |
521 | used to represent a transaction, which finishes at some point and delivers |
514 | a result. |
522 | a result. And yet some people know them as "futures" - a promise to |
|
|
523 | compute/deliver something that you can wait for. |
515 | |
524 | |
516 | Condition variables are very useful to signal that something has finished, |
525 | Condition variables are very useful to signal that something has finished, |
517 | for example, if you write a module that does asynchronous http requests, |
526 | for example, if you write a module that does asynchronous http requests, |
518 | then a condition variable would be the ideal candidate to signal the |
527 | then a condition variable would be the ideal candidate to signal the |
519 | availability of results. The user can either act when the callback is |
528 | availability of results. The user can either act when the callback is |
… | |
… | |
1058 | |
1067 | |
1059 | BEGIN { AnyEvent::common_sense } |
1068 | BEGIN { AnyEvent::common_sense } |
1060 | |
1069 | |
1061 | use Carp (); |
1070 | use Carp (); |
1062 | |
1071 | |
1063 | our $VERSION = 4.85; |
1072 | our $VERSION = 4.86; |
1064 | our $MODEL; |
1073 | our $MODEL; |
1065 | |
1074 | |
1066 | our $AUTOLOAD; |
1075 | our $AUTOLOAD; |
1067 | our @ISA; |
1076 | our @ISA; |
1068 | |
1077 | |