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.42 by root, Sun Aug 9 00:41:49 2009 UTC vs.
Revision 1.47 by root, Thu Aug 13 01:57:10 2009 UTC

… …
38 # monitoring 38 # monitoring
39 mon $port, $cb->(@msg) # callback is invoked on death 39 mon $port, $cb->(@msg) # callback is invoked on death
40 mon $port, $otherport # kill otherport on abnormal death 40 mon $port, $otherport # kill otherport on abnormal death
41 mon $port, $otherport, @msg # send message on death 41 mon $port, $otherport, @msg # send message on death
42 42
43=head1 CURRENT STATUS
44
45 AnyEvent::MP - stable API, should work
46 AnyEvent::MP::Intro - outdated
47 AnyEvent::MP::Kernel - WIP
48 AnyEvent::MP::Transport - mostly stable
49
50 stay tuned.
51
43=head1 DESCRIPTION 52=head1 DESCRIPTION
44 53
45This module (-family) implements a simple message passing framework. 54This module (-family) implements a simple message passing framework.
46 55
47Despite its simplicity, you can securely message other processes running 56Despite its simplicity, you can securely message other processes running
… …
50For an introduction to this module family, see the L<AnyEvent::MP::Intro> 59For an introduction to this module family, see the L<AnyEvent::MP::Intro>
51manual page. 60manual page.
52 61
53At the moment, this module family is severly broken and underdocumented, 62At the moment, this module family is severly broken and underdocumented,
54so do not use. This was uploaded mainly to reserve the CPAN namespace - 63so do not use. This was uploaded mainly to reserve the CPAN namespace -
55stay tuned! The basic API should be finished, however. 64stay tuned!
56 65
57=head1 CONCEPTS 66=head1 CONCEPTS
58 67
59=over 4 68=over 4
60 69
… …
105 114
106=cut 115=cut
107 116
108package AnyEvent::MP; 117package AnyEvent::MP;
109 118
110use AnyEvent::MP::Base; 119use AnyEvent::MP::Kernel;
111 120
112use common::sense; 121use common::sense;
113 122
114use Carp (); 123use Carp ();
115 124
116use AE (); 125use AE ();
117 126
118use base "Exporter"; 127use base "Exporter";
119 128
120our $VERSION = '0.1'; 129our $VERSION = $AnyEvent::MP::Kernel::VERSION;
130
121our @EXPORT = qw( 131our @EXPORT = qw(
122 NODE $NODE *SELF node_of _any_ 132 NODE $NODE *SELF node_of _any_
123 resolve_node initialise_node 133 resolve_node initialise_node
124 snd rcv mon kil reg psub spawn 134 snd rcv mon kil reg psub spawn
125 port 135 port
… …
518In the first form (callback), the callback is simply called with any 528In the first form (callback), the callback is simply called with any
519number of C<@reason> elements (no @reason means that the port was deleted 529number of C<@reason> elements (no @reason means that the port was deleted
520"normally"). Note also that I<< the callback B<must> never die >>, so use 530"normally"). Note also that I<< the callback B<must> never die >>, so use
521C<eval> if unsure. 531C<eval> if unsure.
522 532
523In the second form (another port given), the other port (C<$rcvport) 533In the second form (another port given), the other port (C<$rcvport>)
524will be C<kil>'ed with C<@reason>, iff a @reason was specified, i.e. on 534will be C<kil>'ed with C<@reason>, iff a @reason was specified, i.e. on
525"normal" kils nothing happens, while under all other conditions, the other 535"normal" kils nothing happens, while under all other conditions, the other
526port is killed with the same reason. 536port is killed with the same reason.
527 537
528The third form (kill self) is the same as the second form, except that 538The third form (kill self) is the same as the second form, except that
… …
845This also saves round-trips and avoids sending messages to the wrong port 855This also saves round-trips and avoids sending messages to the wrong port
846(hard to do in Erlang). 856(hard to do in Erlang).
847 857
848=back 858=back
849 859
860=head1 RATIONALE
861
862=over 4
863
864=item Why strings for ports and noderefs, why not objects?
865
866We considered "objects", but found that the actual number of methods
867thatc an be called are very low. Since port IDs and noderefs travel over
868the network frequently, the serialising/deserialising would add lots of
869overhead, as well as having to keep a proxy object.
870
871Strings can easily be printed, easily serialised etc. and need no special
872procedures to be "valid".
873
874And a a miniport consists of a single closure stored in a global hash - it
875can't become much cheaper.
876
877=item Why favour JSON, why not real serialising format such as Storable?
878
879In fact, any AnyEvent::MP node will happily accept Storable as framing
880format, but currently there is no way to make a node use Storable by
881default.
882
883The default framing protocol is JSON because a) JSON::XS is many times
884faster for small messages and b) most importantly, after years of
885experience we found that object serialisation is causing more problems
886than it gains: Just like function calls, objects simply do not travel
887easily over the network, mostly because they will always be a copy, so you
888always have to re-think your design.
889
890Keeping your messages simple, concentrating on data structures rather than
891objects, will keep your messages clean, tidy and efficient.
892
893=back
894
850=head1 SEE ALSO 895=head1 SEE ALSO
851 896
852L<AnyEvent>. 897L<AnyEvent>.
853 898
854=head1 AUTHOR 899=head1 AUTHOR

Diff Legend

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