[ViewVC] Diff of: cvs/AnyEvent-MP/MP/Intro.pod

Comparing AnyEvent-MP/MP/Intro.pod (file contents):
Revision 1.52 by root, Wed Mar 21 01:14:12 2012 UTC vs.
Revision 1.53 by root, Wed Mar 21 01:36:59 2012 UTC

 "the other side" from the remote node, and all will be cleaned up just
 fine.
 =head2 Services
-Above it was mentioned that C<spawn> automatically loads modules, and this
+Above it was mentioned that C<spawn> automatically loads modules. This can
-can be exploited in various ways.
+be exploited in various useful ways.
 Assume for a moment you put the server into a file called
 F<mymod/chatserver.pm> reachable from the current directory. Then you
 could run a node there with:
    aemp run
 The other nodes could C<spawn> the server by using
-C<mymod::chatserver::client_connect> as init function.
+C<mymod::chatserver::client_connect> as init function - without any other
+configuration.
-Likewise, when you have some service that starts automatically (similar to
+Likewise, when you have some service that starts automatically when loaded
-AnyEvent::MP::Global), then you can configure this service statically:
+(similar to AnyEvent::MP::Global), then you can configure this service
+statically:
    aemp profile mysrvnode services mymod::service::
    aemp run profile mysrvnode
 And the module will automatically be loaded in the node, as specifying a
 module name (with C<::>-suffix) will simply load the module, which is then
 free to do whatever it wants.
 Of course, you can also do it in the much more standard way by writing
 a module (e.g. C<BK::Backend::IRC>), installing it as part of a module
-distribution and then configure nodes, for example, if I want to run the
+distribution and then configure nodes. For example, if I wanted to run the
 Bummskraut IRC backend on a machine named "ruth", I could do this:
    aemp profile ruth addservice BK::Backend::IRC::
 And any F<aemp run> on that host will automatically have the Bummskraut
 IRC backend running.
-That's plenty of possibilities you can use - it's all up to you how you
+There are plenty of possibilities you can use - it's all up to you how you
 structure your application.
 =head1 PART 4: Coro::MP - selective receive
 Not all problems lend themselves naturally to an event-based solution:
 sometimes things are easier if you can decide in what order you want to
-receive messages, irregardless of the order in which they were sent.
+receive messages, regardless of the order in which they were sent.
 In these cases, L<Coro::MP> can provide a nice solution: instead of
-registering callbacks for each message type, C<Coro::MP> attached a
+registering callbacks for each message type, C<Coro::MP> attaches a
 (coro-) thread to a port. The thread can then opt to selectively receive
 messages it is interested in. Other messages are not lost, but queued, and
 can be received at a later time.
 The C<Coro::MP> module is not part of L<AnyEvent::MP>, but a separate
    mon $ioserver, sub {
       warn "ioserver was killed: @_\n";
    };
-Let's go through it part by part.
+Let's go through it, section by section.
    my $ioserver = port_async {
 Ports can be created by attaching a thread to an existing port via
-C<rcv_async>, or as here by calling C<port_async> with the code to execute
+C<rcv_async>, or as in this example, by calling C<port_async> with the
-as a thread. The C<async> component comes from the fact that threads are
+code to execute as a thread. The C<async> component comes from the fact
-created using the C<Coro::async> function.
+that threads are created using the C<Coro::async> function.
 The thread runs in a normal port context (so C<$SELF> is set). In
 addition, when the thread returns, it will be C<kil> I<normally>, i.e.
 without a reason argument.
       while () {
          my ($tag, $port, $path) = get_cond;
             or die "only write_file messages expected";
-The thread is supposed to serve many file writes, which is why it executes
+The thread is supposed to serve many file writes, which is why it
-in a loop. The first thing it does is fetch the next message, using
+executes in a loop. The first thing it does is fetch the next message,
-C<get_cond>, the "conditional message get". Without a condition, it simply
+using C<get_cond>, the "conditional message get". Without arguments, it
-fetches the next message from the queue, which I<must> be a C<write_file>
+merely fetches the I<next> message from the queue, which I<must> be a
-message.
+C<write_file> message.
 The message contains the C<$path> to the file, which is then created:
          my $fh = aio_open $path, O_WRONLY|O_CREAT, 0666
             or die "$path: $!";
 The condition must be this strict, as it is possible to receive both
 C<write_file> messages and C<data> messages from other ports while we
 handle the file writing.
-The lone C<5> at the end is a timeout - when no matching message is
+The lone C<5> argument at the end is a timeout - when no matching message
-received within C<5> seconds, we assume an error and C<die>.
+is received within C<5> seconds, we assume an error and C<die>.
 When an empty C<data> message is received we are done and can close the
 file (which is done automatically as C<$fh> goes out of scope):
             length $data or last;
 Otherwise we need to write the data:
             aio_write $fh, undef, undef, $data, 0;
-That's basically it. Note that every process should have some kind of
+And that's basically it. Note that every port thread should have some
-supervisor. In our case, the supervisor simply prints any error message:
+kind of supervisor. In our case, the supervisor simply prints any error
+message:
    mon $ioserver, sub {
       warn "ioserver was killed: @_\n";
    };
 This is simpler, but when some other code part sends an unexpected message
 to the C<$ioserver> it will stay in the queue forever. As a rule of thumb,
 every threaded port should have a "fetch next message unconditionally"
 somewhere, to avoid filling up the queue.
-It is also possible to switch-like C<get_conds>:
+Finally, it is also possible to use more switch-like C<get_conds>:
   get_cond {
      $_[0] eq "msg1" and return sub {
         my (undef, @msg1_data) = @_;
         ...;
 =head1 THE END
 This is the end of this introduction, but hopefully not the end of
 your career as AEMP user. I hope the tutorial was enough to make the
 basic concepts clear. Keep in mind that distributed programming is not
-completely trivial, that AnyEvent::MP is still in it's infancy, and I hope
+completely trivial, in fact, it's pretty complicated. We hope AEMP makes
-it will be useful to create exciting new applications.
+it simpler and will be useful to create exciting new applications.
 =head1 SEE ALSO
 L<AnyEvent::MP>

Diff Legend

-–
+Removed lines
-+
+Added lines
-<
+Changed lines
->
+Changed lines

Comparing AnyEvent-MP/MP/Intro.pod (file contents): Revision 1.52 by root, Wed Mar 21 01:14:12 2012 UTC vs. Revision 1.53 by root, Wed Mar 21 01:36:59 2012 UTC

Diff Legend

Comparing AnyEvent-MP/MP/Intro.pod (file contents):
Revision 1.52 by root, Wed Mar 21 01:14:12 2012 UTC vs.
Revision 1.53 by root, Wed Mar 21 01:36:59 2012 UTC