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.76 by root, Mon Aug 31 18:45:05 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 - epxlains most concepts. 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
… …
179named 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
180-n>) will be used as profile name. 180-n>) will be used as profile name.
181 181
182The profile data is then gathered as follows: 182The profile data is then gathered as follows:
183 183
184First, all remaining key => value pairs (all of which are conviniently 184First, all remaining key => value pairs (all of which are conveniently
185undocumented at the moment) will be interpreted as configuration 185undocumented at the moment) will be interpreted as configuration
186data. 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
187default configuration (see the F<aemp> utility), then the chain of 187default configuration (see the F<aemp> utility), then the chain of
188profiles chosen by the profile name (and any C<parent> attributes). 188profiles chosen by the profile name (and any C<parent> attributes).
189 189
… …
489number 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
490"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
491C<eval> if unsure. 491C<eval> if unsure.
492 492
493In the second form (another port given), the other port (C<$rcvport>) 493In the second form (another port given), the other port (C<$rcvport>)
494will 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
495"normal" kils nothing happens, while under all other conditions, the other 495"normal" kils nothing happens, while under all other conditions, the other
496port is killed with the same reason. 496port is killed with the same reason.
497 497
498The 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
499C<$rvport> defaults to C<$SELF>. 499C<$rvport> defaults to C<$SELF>.
… …
502C<snd>. 502C<snd>.
503 503
504As 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
505a 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
506lost, just like any other message. Another less obvious reason is that 506lost, just like any other message. Another less obvious reason is that
507even monitoring requests can get lost (for exmaple, when the connection 507even monitoring requests can get lost (for example, when the connection
508to the other node goes down permanently). When monitoring a port locally 508to the other node goes down permanently). When monitoring a port locally
509these problems do not exist. 509these problems do not exist.
510 510
511Example: call a given callback when C<$port> is killed. 511Example: call a given callback when C<$port> is killed.
512 512
… …
705 705
706=item * Node IDs are arbitrary strings in AEMP. 706=item * Node IDs are arbitrary strings in AEMP.
707 707
708Erlang 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
709way. 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
710configuraiton or DNS), but will otherwise discover other odes itself. 710configuration or DNS), but will otherwise discover other odes itself.
711 711
712=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
713uses "local ports are like remote ports". 713uses "local ports are like remote ports".
714 714
715The failure modes for local ports are quite different (runtime errors 715The failure modes for local ports are quite different (runtime errors
… …
728 728
729Erlang uses processes that selectively receive messages, and therefore 729Erlang uses processes that selectively receive messages, and therefore
730needs a queue. AEMP is event based, queuing messages would serve no 730needs a queue. AEMP is event based, queuing messages would serve no
731useful purpose. For the same reason the pattern-matching abilities of 731useful purpose. For the same reason the pattern-matching abilities of
732AnyEvent::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
733filter messages without dequeing them. 733filter messages without dequeuing them.
734 734
735(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).
736 736
737=item * Erlang sends are synchronous, AEMP sends are asynchronous. 737=item * Erlang sends are synchronous, AEMP sends are asynchronous.
738 738

Diff Legend

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