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

Comparing AnyEvent-MP/MP.pm (file contents):
Revision 1.106 by root, Wed Dec 9 14:00:49 2009 UTC vs.
Revision 1.117 by root, Wed Oct 27 06:32:39 2010 UTC

    rcv $port, pong => sub { warn "pong received\n" };
    # create a port on another node
    my $port = spawn $node, $initfunc, @initdata;
-   # destroy a prot again
+   # destroy a port again
    kil $port;  # "normal" kill
    kil $port, my_error => "everything is broken"; # error kill
    # monitoring
    mon $localport, $cb->(@msg)      # callback is invoked on death
 Nodes are either public (have one or more listening ports) or private
 (no listening ports). Private nodes cannot talk to other private nodes
 currently.
-=item node ID - C<[A-Z_][a-zA-Z0-9_\-.:]*>
+=item node ID - C<[A-Za-z0-9_\-.:]*>
 A node ID is a string that uniquely identifies the node within a
 network. Depending on the configuration used, node IDs can look like a
 hostname, a hostname and a port, or a random string. AnyEvent::MP itself
 doesn't interpret node IDs in any way.
 use AE ();
 use base "Exporter";
-our $VERSION = 1.24;
+our $VERSION = 1.29;
 our @EXPORT = qw(
    NODE $NODE *SELF node_of after
    configure
    snd rcv mon mon_guard kil psub peval spawn cal
 Before a node can talk to other nodes on the network (i.e. enter
 "distributed mode") it has to configure itself - the minimum a node needs
 to know is its own name, and optionally it should know the addresses of
 some other nodes in the network to discover other nodes.
+The key/value pairs are basically the same ones as documented for the
+F<aemp> command line utility (sans the set/del prefix).
 This function configures a node - it must be called exactly once (or
 never) before calling other AnyEvent::MP functions.
 =over 4
 Remembers C<$SELF> and creates a closure out of the BLOCK. When the
 closure is executed, sets up the environment in the same way as in C<rcv>
 callbacks, i.e. runtime errors will cause the port to get C<kil>ed.
 The effect is basically as if it returned C<< sub { peval $SELF, sub {
-BLOCK } } >>.
+BLOCK }, @_ } >>.
 This is useful when you register callbacks from C<rcv> callbacks:
    rcv delayed_reply => sub {
       my ($delay, @reply) = @_;
 =item kil $port[, @reason]
 Kill the specified port with the given C<@reason>.
-If no C<@reason> is specified, then the port is killed "normally" (ports
+If no C<@reason> is specified, then the port is killed "normally" -
-monitoring other ports will not necessarily die because a port dies
+monitor callback will be invoked, but the kil will not cause linked ports
-"normally").
+(C<mon $mport, $lport> form) to get killed.
-Otherwise, linked ports get killed with the same reason (second form of
+If a C<@reason> is specified, then linked ports (C<mon $mport, $lport>
-C<mon>, see above).
+form) get killed with the same reason.
 Runtime errors while evaluating C<rcv> callbacks or inside C<psub> blocks
 will be reported as reason C<< die => $@ >>.
 Transport/communication errors are reported as C<< transport_error =>
 Erlang implements few guarantees on messages delivery - messages can get
 lost without any of the processes realising it (i.e. you send messages a,
 b, and c, and the other side only receives messages a and c).
-AEMP guarantees correct ordering, and the guarantee that after one message
+AEMP guarantees (modulo hardware errors) correct ordering, and the
-is lost, all following ones sent to the same port are lost as well, until
+guarantee that after one message is lost, all following ones sent to the
-monitoring raises an error, so there are no silent "holes" in the message
+same port are lost as well, until monitoring raises an error, so there are
-sequence.
+no silent "holes" in the message sequence.
 =item * Erlang can send messages to the wrong port, AEMP does not.
 In Erlang it is quite likely that a node that restarts reuses a process ID
 known to other nodes for a completely different process, causing messages
 overhead, as well as having to keep a proxy object everywhere.
 Strings can easily be printed, easily serialised etc. and need no special
 procedures to be "valid".
-And as a result, a miniport consists of a single closure stored in a
+And as a result, a port with just a default receiver consists of a single
-global hash - it can't become much cheaper.
+code reference stored in a global hash - it can't become much cheaper.
 =item Why favour JSON, why not a real serialising format such as Storable?
 In fact, any AnyEvent::MP node will happily accept Storable as framing
 format, but currently there is no way to make a node use Storable by
 L<AnyEvent::MP::Intro> - a gentle introduction.
 L<AnyEvent::MP::Kernel> - more, lower-level, stuff.
-L<AnyEvent::MP::Global> - network maintainance and port groups, to find
+L<AnyEvent::MP::Global> - network maintenance and port groups, to find
 your applications.
 L<AnyEvent::MP::DataConn> - establish data connections between nodes.
 L<AnyEvent::MP::LogCatcher> - simple service to display log messages from

Diff Legend

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

Comparing AnyEvent-MP/MP.pm (file contents): Revision 1.106 by root, Wed Dec 9 14:00:49 2009 UTC vs. Revision 1.117 by root, Wed Oct 27 06:32:39 2010 UTC

Diff Legend

Comparing AnyEvent-MP/MP.pm (file contents):
Revision 1.106 by root, Wed Dec 9 14:00:49 2009 UTC vs.
Revision 1.117 by root, Wed Oct 27 06:32:39 2010 UTC