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.77 by elmex, Thu Sep 3 07:57:30 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
… …
181named C<profile> parameter. If it is missing, then the nodename (F<uname 179named C<profile> parameter. If it is missing, then the nodename (F<uname
182-n>) will be used as profile name. 180-n>) will be used as profile name.
183 181
184The profile data is then gathered as follows: 182The profile data is then gathered as follows:
185 183
186First, all remaining key => value pairs (all of which are conviniently 184First, all remaining key => value pairs (all of which are conveniently
187undocumented at the moment) will be interpreted as configuration 185undocumented at the moment) will be interpreted as configuration
188data. Then they will be overwritten by any values specified in the global 186data. Then they will be overwritten by any values specified in the global
189default configuration (see the F<aemp> utility), then the chain of 187default configuration (see the F<aemp> utility), then the chain of
190profiles chosen by the profile name (and any C<parent> attributes). 188profiles chosen by the profile name (and any C<parent> attributes).
191 189
… …
491number of C<@reason> elements (no @reason means that the port was deleted 489number 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 490"normally"). Note also that I<< the callback B<must> never die >>, so use
493C<eval> if unsure. 491C<eval> if unsure.
494 492
495In the second form (another port given), the other port (C<$rcvport>) 493In 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 494will 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 495"normal" kils nothing happens, while under all other conditions, the other
498port is killed with the same reason. 496port is killed with the same reason.
499 497
500The third form (kill self) is the same as the second form, except that 498The third form (kill self) is the same as the second form, except that
501C<$rvport> defaults to C<$SELF>. 499C<$rvport> defaults to C<$SELF>.
… …
504C<snd>. 502C<snd>.
505 503
506As a rule of thumb, monitoring requests should always monitor a port from 504As 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 505a local port (or callback). The reason is that kill messages might get
508lost, just like any other message. Another less obvious reason is that 506lost, just like any other message. Another less obvious reason is that
509even monitoring requests can get lost (for exmaple, when the connection 507even monitoring requests can get lost (for example, when the connection
510to the other node goes down permanently). When monitoring a port locally 508to the other node goes down permanently). When monitoring a port locally
511these problems do not exist. 509these problems do not exist.
512 510
513Example: call a given callback when C<$port> is killed. 511Example: call a given callback when C<$port> is killed.
514 512
… …
707 705
708=item * Node IDs are arbitrary strings in AEMP. 706=item * Node IDs are arbitrary strings in AEMP.
709 707
710Erlang relies on special naming and DNS to work everywhere in the same 708Erlang 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 709way. AEMP relies on each node somehow knowing its own address(es) (e.g. by
712configuraiton or DNS), but will otherwise discover other odes itself. 710configuration or DNS), but will otherwise discover other odes itself.
713 711
714=item * Erlang has a "remote ports are like local ports" philosophy, AEMP 712=item * Erlang has a "remote ports are like local ports" philosophy, AEMP
715uses "local ports are like remote ports". 713uses "local ports are like remote ports".
716 714
717The failure modes for local ports are quite different (runtime errors 715The failure modes for local ports are quite different (runtime errors
… …
730 728
731Erlang uses processes that selectively receive messages, and therefore 729Erlang uses processes that selectively receive messages, and therefore
732needs a queue. AEMP is event based, queuing messages would serve no 730needs a queue. AEMP is event based, queuing messages would serve no
733useful purpose. For the same reason the pattern-matching abilities of 731useful purpose. For the same reason the pattern-matching abilities of
734AnyEvent::MP are more limited, as there is little need to be able to 732AnyEvent::MP are more limited, as there is little need to be able to
735filter messages without dequeing them. 733filter messages without dequeuing them.
736 734
737(But see L<Coro::MP> for a more Erlang-like process model on top of AEMP). 735(But see L<Coro::MP> for a more Erlang-like process model on top of AEMP).
738 736
739=item * Erlang sends are synchronous, AEMP sends are asynchronous. 737=item * Erlang sends are synchronous, AEMP sends are asynchronous.
740 738

Diff Legend

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