| … | |
… | |
| 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 | |
| 45 | This module (-family) implements a simple message passing framework. |
54 | This module (-family) implements a simple message passing framework. |
| 46 | |
55 | |
| 47 | Despite its simplicity, you can securely message other processes running |
56 | Despite its simplicity, you can securely message other processes running |
| … | |
… | |
| 50 | For an introduction to this module family, see the L<AnyEvent::MP::Intro> |
59 | For an introduction to this module family, see the L<AnyEvent::MP::Intro> |
| 51 | manual page. |
60 | manual page. |
| 52 | |
61 | |
| 53 | At the moment, this module family is severly broken and underdocumented, |
62 | At the moment, this module family is severly broken and underdocumented, |
| 54 | so do not use. This was uploaded mainly to reserve the CPAN namespace - |
63 | so do not use. This was uploaded mainly to reserve the CPAN namespace - |
| 55 | stay tuned! The basic API should be finished, however. |
64 | stay tuned! |
| 56 | |
65 | |
| 57 | =head1 CONCEPTS |
66 | =head1 CONCEPTS |
| 58 | |
67 | |
| 59 | =over 4 |
68 | =over 4 |
| 60 | |
69 | |
| … | |
… | |
| 846 | This also saves round-trips and avoids sending messages to the wrong port |
855 | This 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 | |
|
|
866 | We considered "objects", but found that the actual number of methods |
|
|
867 | thatc an be called are very low. Since port IDs and noderefs travel over |
|
|
868 | the network frequently, the serialising/deserialising would add lots of |
|
|
869 | overhead, as well as having to keep a proxy object. |
|
|
870 | |
|
|
871 | Strings can easily be printed, easily serialised etc. and need no special |
|
|
872 | procedures to be "valid". |
|
|
873 | |
|
|
874 | =item Why favour JSON, why not real serialising format such as Storable? |
|
|
875 | |
|
|
876 | In fact, any AnyEvent::MP node will happily accept Storable as framing |
|
|
877 | format, but currently there is no way to make a node use Storable by |
|
|
878 | default. |
|
|
879 | |
|
|
880 | The default framing protocol is JSON because a) JSON::XS is many times |
|
|
881 | faster for small messages and b) most importantly, after years of |
|
|
882 | experience we found that object serialisation is causing more problems |
|
|
883 | than it gains: Just like function calls, objects simply do not travel |
|
|
884 | easily over the network, mostly because they will always be a copy, so you |
|
|
885 | always have to re-think your design. |
|
|
886 | |
|
|
887 | Keeping your messages simple, concentrating on data structures rather than |
|
|
888 | objects, will keep your messages clean, tidy and efficient. |
|
|
889 | |
|
|
890 | =back |
|
|
891 | |
| 851 | =head1 SEE ALSO |
892 | =head1 SEE ALSO |
| 852 | |
893 | |
| 853 | L<AnyEvent>. |
894 | L<AnyEvent>. |
| 854 | |
895 | |
| 855 | =head1 AUTHOR |
896 | =head1 AUTHOR |
