… | |
… | |
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 | |
… | |
… | |
105 | |
114 | |
106 | =cut |
115 | =cut |
107 | |
116 | |
108 | package AnyEvent::MP; |
117 | package AnyEvent::MP; |
109 | |
118 | |
110 | use AnyEvent::MP::Base; |
119 | use AnyEvent::MP::Kernel; |
111 | |
120 | |
112 | use common::sense; |
121 | use common::sense; |
113 | |
122 | |
114 | use Carp (); |
123 | use Carp (); |
115 | |
124 | |
116 | use AE (); |
125 | use AE (); |
117 | |
126 | |
118 | use base "Exporter"; |
127 | use base "Exporter"; |
119 | |
128 | |
120 | our $VERSION = '0.1'; |
129 | our $VERSION = $AnyEvent::MP::Kernel::VERSION; |
|
|
130 | |
121 | our @EXPORT = qw( |
131 | our @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 |
… | |
… | |
501 | |
511 | |
502 | =item $guard = mon $port |
512 | =item $guard = mon $port |
503 | |
513 | |
504 | =item $guard = mon $port, $rcvport, @msg |
514 | =item $guard = mon $port, $rcvport, @msg |
505 | |
515 | |
506 | Monitor the given port and do something when the port is killed, and |
516 | Monitor the given port and do something when the port is killed or |
507 | optionally return a guard that can be used to stop monitoring again. |
517 | messages to it were lost, and optionally return a guard that can be used |
|
|
518 | to stop monitoring again. |
|
|
519 | |
|
|
520 | C<mon> effectively guarantees that, in the absence of hardware failures, |
|
|
521 | that after starting the monitor, either all messages sent to the port |
|
|
522 | will arrive, or the monitoring action will be invoked after possible |
|
|
523 | message loss has been detected. No messages will be lost "in between" |
|
|
524 | (after the first lost message no further messages will be received by the |
|
|
525 | port). After the monitoring action was invoked, further messages might get |
|
|
526 | delivered again. |
508 | |
527 | |
509 | In the first form (callback), the callback is simply called with any |
528 | In the first form (callback), the callback is simply called with any |
510 | number of C<@reason> elements (no @reason means that the port was deleted |
529 | number of C<@reason> elements (no @reason means that the port was deleted |
511 | "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 |
512 | C<eval> if unsure. |
531 | C<eval> if unsure. |
513 | |
532 | |
514 | In the second form (another port given), the other port (C<$rcvport) |
533 | In the second form (another port given), the other port (C<$rcvport>) |
515 | will be C<kil>'ed with C<@reason>, iff a @reason was specified, i.e. on |
534 | will be C<kil>'ed with C<@reason>, iff a @reason was specified, i.e. on |
516 | "normal" kils nothing happens, while under all other conditions, the other |
535 | "normal" kils nothing happens, while under all other conditions, the other |
517 | port is killed with the same reason. |
536 | port is killed with the same reason. |
518 | |
537 | |
519 | The third form (kill self) is the same as the second form, except that |
538 | The third form (kill self) is the same as the second form, except that |
… | |
… | |
836 | 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 |
837 | (hard to do in Erlang). |
856 | (hard to do in Erlang). |
838 | |
857 | |
839 | =back |
858 | =back |
840 | |
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 | And a a miniport consists of a single closure stored in a global hash - it |
|
|
875 | can't become much cheaper. |
|
|
876 | |
|
|
877 | =item Why favour JSON, why not real serialising format such as Storable? |
|
|
878 | |
|
|
879 | In fact, any AnyEvent::MP node will happily accept Storable as framing |
|
|
880 | format, but currently there is no way to make a node use Storable by |
|
|
881 | default. |
|
|
882 | |
|
|
883 | The default framing protocol is JSON because a) JSON::XS is many times |
|
|
884 | faster for small messages and b) most importantly, after years of |
|
|
885 | experience we found that object serialisation is causing more problems |
|
|
886 | than it gains: Just like function calls, objects simply do not travel |
|
|
887 | easily over the network, mostly because they will always be a copy, so you |
|
|
888 | always have to re-think your design. |
|
|
889 | |
|
|
890 | Keeping your messages simple, concentrating on data structures rather than |
|
|
891 | objects, will keep your messages clean, tidy and efficient. |
|
|
892 | |
|
|
893 | =back |
|
|
894 | |
841 | =head1 SEE ALSO |
895 | =head1 SEE ALSO |
842 | |
896 | |
843 | L<AnyEvent>. |
897 | L<AnyEvent>. |
844 | |
898 | |
845 | =head1 AUTHOR |
899 | =head1 AUTHOR |