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

Comparing AnyEvent-MP/MP.pm (file contents):
Revision 1.146 by root, Mon Jun 20 08:19:19 2016 UTC vs.
Revision 1.154 by root, Fri Nov 15 09:47:38 2019 UTC

 each other. To do this, nodes should listen on one or more local transport
 endpoints - binds.
 Currently, only standard C<ip:port> specifications can be used, which
 specify TCP ports to listen on. So a bind is basically just a tcp socket
-in listening mode that accepts conenctions form other nodes.
+in listening mode that accepts connections from other nodes.
 =item seed nodes
 When a node starts, it knows nothing about the network it is in - it
 needs to connect to at least one other node that is already in the
 Seed nodes themselves are not special - they are seed nodes only because
 some other node I<uses> them as such, but any node can be used as seed
 node for other nodes, and eahc node can use a different set of seed nodes.
 In addition to discovering the network, seed nodes are also used to
-maintain the network - all nodes using the same seed node form are part of
+maintain the network - all nodes using the same seed node are part of the
-the same network. If a network is split into multiple subnets because e.g.
+same network. If a network is split into multiple subnets because e.g. the
-the network link between the parts goes down, then using the same seed
+network link between the parts goes down, then using the same seed nodes
-nodes for all nodes ensures that eventually the subnets get merged again.
+for all nodes ensures that eventually the subnets get merged again.
 Seed nodes are expected to be long-running, and at least one seed node
 should always be available. They should also be relatively responsive - a
 seed node that blocks for long periods will slow down everybody else.
 use AnyEvent ();
 use Guard ();
 use base "Exporter";
-our $VERSION = $AnyEvent::MP::Config::VERSION;
+our $VERSION = '2.02'; # also in MP/Config.pm
 our @EXPORT = qw(
+   configure
    NODE $NODE
-   configure
+   *SELF
    node_of port_is_local
    snd kil
-   db_set db_del
-   db_mon db_family db_keys db_values
-   *SELF
    port rcv mon mon_guard psub peval spawn cal
    db_set db_del db_reg
    db_mon db_family db_keys db_values
    after
 =item step 2, bind listener sockets
 The next step is to look up the binds in the profile, followed by binding
 aemp protocol listeners on all binds specified (it is possible and valid
-to have no binds, meaning that the node cannot be contacted form the
+to have no binds, meaning that the node cannot be contacted from the
 outside. This means the node cannot talk to other nodes that also have no
 binds, but it can still talk to all "normal" nodes).
 If the profile does not specify a binds list, then a default of C<*> is
 used, meaning the node will bind on a dynamically-assigned port on every
 =cut
 sub rcv($@);
 my $KILME = sub {
-   (my $tag = substr $_[0], 0, 30) =~ s/([\x20-\x7e])/./g;
+   (my $tag = substr $_[0], 0, 30) =~ s/([^\x20-\x7e])/./g;
    kil $SELF, unhandled_message => "no callback found for message '$tag'";
 };
 sub port(;&) {
    my $id = $UNIQ . ++$ID;
    $port
 }
 =item peval $port, $coderef[, @args]
-Evaluates the given C<$codref> within the contetx of C<$port>, that is,
+Evaluates the given C<$codref> within the context of C<$port>, that is,
 when the code throws an exception the C<$port> will be killed.
 Any remaining args will be passed to the callback. Any return values will
 be returned to the caller.
 In the last form (message), a message of the form C<$rcvport, @msg,
 @reason> will be C<snd>.
 Monitoring-actions are one-shot: once messages are lost (and a monitoring
 alert was raised), they are removed and will not trigger again, even if it
-turns out that the port is still alive.
+turns out that the port is still alive (but monitoring actions added after
+that will again trigger).
 As a rule of thumb, monitoring requests should always monitor a remote
 port locally (using a local C<$rcvport> or a callback). The reason is that
 kill messages might get lost, just like any other message. Another less
 obvious reason is that even monitoring requests can get lost (for example,
 #=item $cb2 = timeout $seconds, $cb[, @args]
 =item cal $port, @msg, $callback[, $timeout]
 A simple form of RPC - sends a message to the given C<$port> with the
-given contents (C<@msg>), but adds a reply port to the message.
+given contents (C<@msg>), but appends a reply port to the message.
 The reply port is created temporarily just for the purpose of receiving
 the reply, and will be C<kil>ed when no longer needed.
 A reply message sent to the port is passed to the C<$callback> as-is.
 top of AEMP and Coro threads.
 =item * Erlang sends are synchronous, AEMP sends are asynchronous.
 Sending messages in Erlang is synchronous and blocks the process until
-a conenction has been established and the message sent (and so does not
+a connection has been established and the message sent (and so does not
 need a queue that can overflow). AEMP sends return immediately, connection
 establishment is handled in the background.
 =item * Erlang suffers from silent message loss, AEMP does not.
 C<grp_mon> can be replaced by C<db_mon> with minor changes - C<db_mon>
 passes a hash as first argument, and an extra C<$chg> argument that can be
 ignored:
   db_mon $group => sub {
-     my ($ports, $add, $chg, $lde) = @_;
+     my ($ports, $add, $chg, $del) = @_;
      $ports = [keys %$ports];
      # now $ports, $add and $del are the same as
      # were originally passed by grp_mon.
      ...
 =back
 =head1 LOGGING
 AnyEvent::MP does not normally log anything by itself, but since it is the
-root of the contetx hierarchy for AnyEvent::MP modules, it will receive
+root of the context hierarchy for AnyEvent::MP modules, it will receive
 all log messages by submodules.
 =head1 SEE ALSO
 L<AnyEvent::MP::Intro> - a gentle introduction.

Diff Legend

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

Comparing AnyEvent-MP/MP.pm (file contents): Revision 1.146 by root, Mon Jun 20 08:19:19 2016 UTC vs. Revision 1.154 by root, Fri Nov 15 09:47:38 2019 UTC

Diff Legend

Comparing AnyEvent-MP/MP.pm (file contents):
Revision 1.146 by root, Mon Jun 20 08:19:19 2016 UTC vs.
Revision 1.154 by root, Fri Nov 15 09:47:38 2019 UTC