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

Comparing AnyEvent-MP/MP.pm (file contents):
Revision 1.75 by root, Mon Aug 31 13:18:06 2009 UTC vs.
Revision 1.78 by root, Thu Sep 3 20:16:36 2009 UTC

… …
39 39
40=head1 CURRENT STATUS 40=head1 CURRENT STATUS
41 41
42 bin/aemp - stable. 42 bin/aemp - stable.
43 AnyEvent::MP - stable API, should work. 43 AnyEvent::MP - stable API, should work.
44 AnyEvent::MP::Intro - uptodate, but incomplete. 44 AnyEvent::MP::Intro - explains most concepts.
45 AnyEvent::MP::Kernel - mostly stable. 45 AnyEvent::MP::Kernel - mostly stable.
46 AnyEvent::MP::Global - stable API, protocol not yet final. 46 AnyEvent::MP::Global - stable API, protocol not yet final.
47 47
48 stay tuned. 48 stay tuned.
49 49
… …
54Despite its simplicity, you can securely message other processes running 54Despite its simplicity, you can securely message other processes running
55on the same or other hosts, and you can supervise entities remotely. 55on the same or other hosts, and you can supervise entities remotely.
56 56
57For an introduction to this module family, see the L<AnyEvent::MP::Intro> 57For an introduction to this module family, see the L<AnyEvent::MP::Intro>
58manual page and the examples under F<eg/>. 58manual page and the examples under F<eg/>.
59
60At the moment, this module family is a bit underdocumented.
61 59
62=head1 CONCEPTS 60=head1 CONCEPTS
63 61
64=over 4 62=over 4
65 63
… …
160 158
161=item $nodeid = node_of $port 159=item $nodeid = node_of $port
162 160
163Extracts and returns the node ID from a port ID or a node ID. 161Extracts and returns the node ID from a port ID or a node ID.
164 162
163=item configure $profile, key => value...
164
165=item configure key => value... 165=item configure key => value...
166 166
167Before a node can talk to other nodes on the network (i.e. enter 167Before a node can talk to other nodes on the network (i.e. enter
168"distributed mode") it has to configure itself - the minimum a node needs 168"distributed mode") it has to configure itself - the minimum a node needs
169to know is its own name, and optionally it should know the addresses of 169to know is its own name, and optionally it should know the addresses of
… …
176 176
177=item step 1, gathering configuration from profiles 177=item step 1, gathering configuration from profiles
178 178
179The function first looks up a profile in the aemp configuration (see the 179The function first looks up a profile in the aemp configuration (see the
180L<aemp> commandline utility). The profile name can be specified via the 180L<aemp> commandline utility). The profile name can be specified via the
181named C<profile> parameter. If it is missing, then the nodename (F<uname 181named C<profile> parameter or can simply be the first parameter). If it is
182-n>) will be used as profile name. 182missing, then the nodename (F<uname -n>) will be used as profile name.
183 183
184The profile data is then gathered as follows: 184The profile data is then gathered as follows:
185 185
186First, all remaining key => value pairs (all of which are conviniently 186First, all remaining key => value pairs (all of which are conveniently
187undocumented at the moment) will be interpreted as configuration 187undocumented at the moment) will be interpreted as configuration
188data. Then they will be overwritten by any values specified in the global 188data. Then they will be overwritten by any values specified in the global
189default configuration (see the F<aemp> utility), then the chain of 189default configuration (see the F<aemp> utility), then the chain of
190profiles chosen by the profile name (and any C<parent> attributes). 190profiles chosen by the profile name (and any C<parent> attributes).
191 191
… …
491number of C<@reason> elements (no @reason means that the port was deleted 491number of C<@reason> elements (no @reason means that the port was deleted
492"normally"). Note also that I<< the callback B<must> never die >>, so use 492"normally"). Note also that I<< the callback B<must> never die >>, so use
493C<eval> if unsure. 493C<eval> if unsure.
494 494
495In the second form (another port given), the other port (C<$rcvport>) 495In the second form (another port given), the other port (C<$rcvport>)
496will be C<kil>'ed with C<@reason>, iff a @reason was specified, i.e. on 496will be C<kil>'ed with C<@reason>, if a @reason was specified, i.e. on
497"normal" kils nothing happens, while under all other conditions, the other 497"normal" kils nothing happens, while under all other conditions, the other
498port is killed with the same reason. 498port is killed with the same reason.
499 499
500The third form (kill self) is the same as the second form, except that 500The third form (kill self) is the same as the second form, except that
501C<$rvport> defaults to C<$SELF>. 501C<$rvport> defaults to C<$SELF>.
… …
504C<snd>. 504C<snd>.
505 505
506As a rule of thumb, monitoring requests should always monitor a port from 506As a rule of thumb, monitoring requests should always monitor a port from
507a local port (or callback). The reason is that kill messages might get 507a local port (or callback). The reason is that kill messages might get
508lost, just like any other message. Another less obvious reason is that 508lost, just like any other message. Another less obvious reason is that
509even monitoring requests can get lost (for exmaple, when the connection 509even monitoring requests can get lost (for example, when the connection
510to the other node goes down permanently). When monitoring a port locally 510to the other node goes down permanently). When monitoring a port locally
511these problems do not exist. 511these problems do not exist.
512 512
513Example: call a given callback when C<$port> is killed. 513Example: call a given callback when C<$port> is killed.
514 514
… …
707 707
708=item * Node IDs are arbitrary strings in AEMP. 708=item * Node IDs are arbitrary strings in AEMP.
709 709
710Erlang relies on special naming and DNS to work everywhere in the same 710Erlang relies on special naming and DNS to work everywhere in the same
711way. AEMP relies on each node somehow knowing its own address(es) (e.g. by 711way. AEMP relies on each node somehow knowing its own address(es) (e.g. by
712configuraiton or DNS), but will otherwise discover other odes itself. 712configuration or DNS), but will otherwise discover other odes itself.
713 713
714=item * Erlang has a "remote ports are like local ports" philosophy, AEMP 714=item * Erlang has a "remote ports are like local ports" philosophy, AEMP
715uses "local ports are like remote ports". 715uses "local ports are like remote ports".
716 716
717The failure modes for local ports are quite different (runtime errors 717The failure modes for local ports are quite different (runtime errors
… …
730 730
731Erlang uses processes that selectively receive messages, and therefore 731Erlang uses processes that selectively receive messages, and therefore
732needs a queue. AEMP is event based, queuing messages would serve no 732needs a queue. AEMP is event based, queuing messages would serve no
733useful purpose. For the same reason the pattern-matching abilities of 733useful purpose. For the same reason the pattern-matching abilities of
734AnyEvent::MP are more limited, as there is little need to be able to 734AnyEvent::MP are more limited, as there is little need to be able to
735filter messages without dequeing them. 735filter messages without dequeuing them.
736 736
737(But see L<Coro::MP> for a more Erlang-like process model on top of AEMP). 737(But see L<Coro::MP> for a more Erlang-like process model on top of AEMP).
738 738
739=item * Erlang sends are synchronous, AEMP sends are asynchronous. 739=item * Erlang sends are synchronous, AEMP sends are asynchronous.
740 740

Diff Legend

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