ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/AnyEvent/lib/AnyEvent.pm
(Generate patch)

Comparing AnyEvent/lib/AnyEvent.pm (file contents):
Revision 1.248 by root, Sat Jul 18 22:27:10 2009 UTC vs.
Revision 1.253 by root, Tue Jul 21 06:00:47 2009 UTC

1=head1 NAME 1=head1 NAME
2 2
3AnyEvent - provide framework for multiple event loops 3AnyEvent - events independent of event loop implementation
4 4
5EV, Event, Glib, Tk, Perl, Event::Lib, Qt and POE are various supported 5EV, Event, Glib, Tk, Perl, Event::Lib, Qt and POE are various supported
6event loops. 6event loops.
7 7
8=head1 SYNOPSIS 8=head1 SYNOPSIS
40=head1 INTRODUCTION/TUTORIAL 40=head1 INTRODUCTION/TUTORIAL
41 41
42This manpage is mainly a reference manual. If you are interested 42This manpage is mainly a reference manual. If you are interested
43in a tutorial or some gentle introduction, have a look at the 43in a tutorial or some gentle introduction, have a look at the
44L<AnyEvent::Intro> manpage. 44L<AnyEvent::Intro> manpage.
45
46=head1 SUPPORT
47
48There is a mailinglist for discussing all things AnyEvent, and an IRC
49channel, too.
50
51See the AnyEvent project page at the B<Schmorpforge Ta-Sa Software
52Respository>, 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
48Glib, POE, IO::Async, Event... CPAN offers event models by the dozen 56Glib, POE, IO::Async, Event... CPAN offers event models by the dozen
49nowadays. So what is different about AnyEvent? 57nowadays. So what is different about AnyEvent?
509Condition variables are similar to callbacks, except that you can 517Condition variables are similar to callbacks, except that you can
510optionally wait for them. They can also be called merge points - points 518optionally wait for them. They can also be called merge points - points
511in time where multiple outstanding events have been processed. And yet 519in time where multiple outstanding events have been processed. And yet
512another way to call them is transactions - each condition variable can be 520another way to call them is transactions - each condition variable can be
513used to represent a transaction, which finishes at some point and delivers 521used to represent a transaction, which finishes at some point and delivers
514a result. 522a result. And yet some people know them as "futures" - a promise to
523compute/deliver something that you can wait for.
515 524
516Condition variables are very useful to signal that something has finished, 525Condition variables are very useful to signal that something has finished,
517for example, if you write a module that does asynchronous http requests, 526for example, if you write a module that does asynchronous http requests,
518then a condition variable would be the ideal candidate to signal the 527then a condition variable would be the ideal candidate to signal the
519availability of results. The user can either act when the callback is 528availability of results. The user can either act when the callback is
870event module detection too early, for example, L<AnyEvent::AIO> creates 879event module detection too early, for example, L<AnyEvent::AIO> creates
871and installs the global L<IO::AIO> watcher in a C<post_detect> block to 880and installs the global L<IO::AIO> watcher in a C<post_detect> block to
872avoid autodetecting the event module at load time. 881avoid autodetecting the event module at load time.
873 882
874If called in scalar or list context, then it creates and returns an object 883If called in scalar or list context, then it creates and returns an object
875that automatically removes the callback again when it is destroyed. See 884that automatically removes the callback again when it is destroyed (or
885C<undef> when the hook was immediately executed). See L<AnyEvent::AIO> for
876L<Coro::BDB> for a case where this is useful. 886a case where this is useful.
887
888Example: Create a watcher for the IO::AIO module and store it in
889C<$WATCHER>. Only do so after the event loop is initialised, though.
890
891 our WATCHER;
892
893 my $guard = AnyEvent::post_detect {
894 $WATCHER = AnyEvent->io (fh => IO::AIO::poll_fileno, poll => 'r', cb => \&IO::AIO::poll_cb);
895 };
896
897 # the ||= is important in case post_detect immediately runs the block,
898 # as to not clobber the newly-created watcher. assigning both watcher and
899 # post_detect guard to the same variable has the advantage of users being
900 # able to just C<undef $WATCHER> if the watcher causes them grief.
901
902 $WATCHER ||= $guard;
877 903
878=item @AnyEvent::post_detect 904=item @AnyEvent::post_detect
879 905
880If there are any code references in this array (you can C<push> to it 906If there are any code references in this array (you can C<push> to it
881before or after loading AnyEvent), then they will called directly after 907before or after loading AnyEvent), then they will called directly after
1058 1084
1059BEGIN { AnyEvent::common_sense } 1085BEGIN { AnyEvent::common_sense }
1060 1086
1061use Carp (); 1087use Carp ();
1062 1088
1063our $VERSION = 4.85; 1089our $VERSION = 4.86;
1064our $MODEL; 1090our $MODEL;
1065 1091
1066our $AUTOLOAD; 1092our $AUTOLOAD;
1067our @ISA; 1093our @ISA;
1068 1094
1126 my ($cb) = @_; 1152 my ($cb) = @_;
1127 1153
1128 if ($MODEL) { 1154 if ($MODEL) {
1129 $cb->(); 1155 $cb->();
1130 1156
1131 1 1157 undef
1132 } else { 1158 } else {
1133 push @post_detect, $cb; 1159 push @post_detect, $cb;
1134 1160
1135 defined wantarray 1161 defined wantarray
1136 ? bless \$cb, "AnyEvent::Util::postdetect" 1162 ? bless \$cb, "AnyEvent::Util::postdetect"

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines