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.44 by root, Wed Aug 12 21:39:58 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
… …
846This 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
847(hard to do in Erlang). 856(hard to do in Erlang).
848 857
849=back 858=back
850 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
851=head1 SEE ALSO 895=head1 SEE ALSO
852 896
853L<AnyEvent>. 897L<AnyEvent>.
854 898
855=head1 AUTHOR 899=head1 AUTHOR

Diff Legend

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