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

Comparing AnyEvent-MP/MP.pm (file contents):
Revision 1.145 by root, Tue Oct 2 13:58:07 2012 UTC vs.
Revision 1.155 by root, Sat Sep 18 13:46:56 2021 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 thta 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
 network. These other nodes are called "seed nodes".
 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 cna use a different set of seed nodes.
+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.
 Any node that loads the L<AnyEvent::MP::Global> module becomes a global
 node and tries to keep connections to all other nodes. So while it can
 make sense to make every node "global" in small networks, it usually makes
 sense to only make seed nodes into global nodes in large networks (nodes
-keep connections to seed nodes and global nodes, so makign them the same
+keep connections to seed nodes and global nodes, so making them the same
 reduces overhead).
 =back
 =head1 VARIABLES/FUNCTIONS
 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
 this process. If not, then the profile name will be used as node ID, with
 a unique randoms tring (C</%u>) appended.
 The node ID can contain some C<%> sequences that are expanded: C<%n>
 is expanded to the local nodename, C<%u> is replaced by a random
-strign to make the node unique. For example, the F<aemp> commandline
+string to make the node unique. For example, the F<aemp> commandline
 utility uses C<aemp/%n/%u> as nodename, which might expand to
 C<aemp/cerebro/ZQDGSIkRhEZQDGSIkRhE>.
 =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.
 Same as C<db_family>, except it only queries the family I<values> and passes them
 as array reference to the callback.
 =item $guard = db_mon $family => $cb->(\%familyhash, \@added, \@changed, \@deleted)
-Creates a monitor on the given database family. Each time a key is set
+Creates a monitor on the given database family. Each time a key is
-or or is deleted the callback is called with a hash containing the
+set or is deleted the callback is called with a hash containing the
 database family and three lists of added, changed and deleted subkeys,
 respectively. If no keys have changed then the array reference might be
 C<undef> or even missing.
 If not called in void context, a guard object is returned that, when
       return unless %$family;
       undef $guard;
       print "My::Module::workers now nonempty\n";
    };
-Example: print all changes to the family "AnyRvent::Fantasy::Module".
+Example: print all changes to the family "AnyEvent::Fantasy::Module".
-   my $guard = db_mon AnyRvent::Fantasy::Module => sub {
+   my $guard = db_mon AnyEvent::Fantasy::Module => sub {
       my ($family, $a, $c, $d) = @_;
       print "+$_=$family->{$_}\n" for @$a;
       print "*$_=$family->{$_}\n" for @$c;
       print "-$_=$family->{$_}\n" for @$d;
 filter messages without dequeuing them.
 This is not a philosophical difference, but simply stems from AnyEvent::MP
 being event-based, while Erlang is process-based.
-You cna have a look at L<Coro::MP> for a more Erlang-like process model on
+You can have a look at L<Coro::MP> for a more Erlang-like process model on
 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 sinc eit is the
+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.145 by root, Tue Oct 2 13:58:07 2012 UTC vs. Revision 1.155 by root, Sat Sep 18 13:46:56 2021 UTC

Diff Legend

Comparing AnyEvent-MP/MP.pm (file contents):
Revision 1.145 by root, Tue Oct 2 13:58:07 2012 UTC vs.
Revision 1.155 by root, Sat Sep 18 13:46:56 2021 UTC