ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/cvsroot/AnyEvent-MP/MP.pm
(Generate patch)

Comparing cvsroot/AnyEvent-MP/MP.pm (file contents):
Revision 1.67 by root, Fri Aug 28 22:21:53 2009 UTC vs.
Revision 1.121 by root, Tue Feb 28 18:37:24 2012 UTC

1=head1 NAME 1=head1 NAME
2 2
3AnyEvent::MP - multi-processing/message-passing framework 3AnyEvent::MP - erlang-style multi-processing/message-passing framework
4 4
5=head1 SYNOPSIS 5=head1 SYNOPSIS
6 6
7 use AnyEvent::MP; 7 use AnyEvent::MP;
8 8
9 $NODE # contains this node's noderef 9 $NODE # contains this node's node ID
10 NODE # returns this node's noderef 10 NODE # returns this node's node ID
11 NODE $port # returns the noderef of the port
12 11
13 $SELF # receiving/own port id in rcv callbacks 12 $SELF # receiving/own port id in rcv callbacks
14 13
15 # initialise the node so it can send/receive messages 14 # initialise the node so it can send/receive messages
16 initialise_node; 15 configure;
17 16
18 # ports are message endpoints 17 # ports are message destinations
19 18
20 # sending messages 19 # sending messages
21 snd $port, type => data...; 20 snd $port, type => data...;
22 snd $port, @msg; 21 snd $port, @msg;
23 snd @msg_with_first_element_being_a_port; 22 snd @msg_with_first_element_being_a_port;
24 23
25 # creating/using ports, the simple way 24 # creating/using ports, the simple way
26 my $simple_port = port { my @msg = @_; 0 }; 25 my $simple_port = port { my @msg = @_ };
27 26
28 # creating/using ports, tagged message matching 27 # creating/using ports, tagged message matching
29 my $port = port; 28 my $port = port;
30 rcv $port, ping => sub { snd $_[0], "pong"; 0 }; 29 rcv $port, ping => sub { snd $_[0], "pong" };
31 rcv $port, pong => sub { warn "pong received\n"; 0 }; 30 rcv $port, pong => sub { warn "pong received\n" };
32 31
33 # create a port on another node 32 # create a port on another node
34 my $port = spawn $node, $initfunc, @initdata; 33 my $port = spawn $node, $initfunc, @initdata;
35 34
35 # destroy a port again
36 kil $port; # "normal" kill
37 kil $port, my_error => "everything is broken"; # error kill
38
36 # monitoring 39 # monitoring
37 mon $port, $cb->(@msg) # callback is invoked on death 40 mon $localport, $cb->(@msg) # callback is invoked on death
38 mon $port, $otherport # kill otherport on abnormal death 41 mon $localport, $otherport # kill otherport on abnormal death
39 mon $port, $otherport, @msg # send message on death 42 mon $localport, $otherport, @msg # send message on death
43
44 # temporarily execute code in port context
45 peval $port, sub { die "kill the port!" };
46
47 # execute callbacks in $SELF port context
48 my $timer = AE::timer 1, 0, psub {
49 die "kill the port, delayed";
50 };
40 51
41=head1 CURRENT STATUS 52=head1 CURRENT STATUS
42 53
54 bin/aemp - stable.
43 AnyEvent::MP - stable API, should work 55 AnyEvent::MP - stable API, should work.
44 AnyEvent::MP::Intro - outdated 56 AnyEvent::MP::Intro - explains most concepts.
45 AnyEvent::MP::Kernel - mostly stable 57 AnyEvent::MP::Kernel - mostly stable API.
46 AnyEvent::MP::Global - mostly stable 58 AnyEvent::MP::Global - stable API.
47 AnyEvent::MP::Node - mostly stable, but internal anyways
48 AnyEvent::MP::Transport - mostly stable, but internal anyways
49
50 stay tuned.
51 59
52=head1 DESCRIPTION 60=head1 DESCRIPTION
53 61
54This module (-family) implements a simple message passing framework. 62This module (-family) implements a simple message passing framework.
55 63
57on the same or other hosts, and you can supervise entities remotely. 65on the same or other hosts, and you can supervise entities remotely.
58 66
59For an introduction to this module family, see the L<AnyEvent::MP::Intro> 67For an introduction to this module family, see the L<AnyEvent::MP::Intro>
60manual page and the examples under F<eg/>. 68manual page and the examples under F<eg/>.
61 69
62At the moment, this module family is a bit underdocumented.
63
64=head1 CONCEPTS 70=head1 CONCEPTS
65 71
66=over 4 72=over 4
67 73
68=item port 74=item port
69 75
70A port is something you can send messages to (with the C<snd> function). 76Not to be confused with a TCP port, a "port" is something you can send
77messages to (with the C<snd> function).
71 78
72Ports allow you to register C<rcv> handlers that can match all or just 79Ports allow you to register C<rcv> handlers that can match all or just
73some messages. Messages send to ports will not be queued, regardless of 80some messages. Messages send to ports will not be queued, regardless of
74anything was listening for them or not. 81anything was listening for them or not.
75 82
83Ports are represented by (printable) strings called "port IDs".
84
76=item port ID - C<nodeid#portname> 85=item port ID - C<nodeid#portname>
77 86
78A port ID is the concatenation of a node ID, a hash-mark (C<#>) as 87A port ID is the concatenation of a node ID, a hash-mark (C<#>) as
79separator, and a port name (a printable string of unspecified format). 88separator, and a port name (a printable string of unspecified format).
80 89
84which enables nodes to manage each other remotely, and to create new 93which enables nodes to manage each other remotely, and to create new
85ports. 94ports.
86 95
87Nodes are either public (have one or more listening ports) or private 96Nodes are either public (have one or more listening ports) or private
88(no listening ports). Private nodes cannot talk to other private nodes 97(no listening ports). Private nodes cannot talk to other private nodes
89currently. 98currently, but all nodes can talk to public nodes.
90 99
100Nodes is represented by (printable) strings called "node IDs".
101
91=item node ID - C<[a-za-Z0-9_\-.:]+> 102=item node ID - C<[A-Za-z0-9_\-.:]*>
92 103
93A node ID is a string that uniquely identifies the node within a 104A node ID is a string that uniquely identifies the node within a
94network. Depending on the configuration used, node IDs can look like a 105network. Depending on the configuration used, node IDs can look like a
95hostname, a hostname and a port, or a random string. AnyEvent::MP itself 106hostname, a hostname and a port, or a random string. AnyEvent::MP itself
96doesn't interpret node IDs in any way. 107doesn't interpret node IDs in any way except to uniquely identify a node.
97 108
98=item binds - C<ip:port> 109=item binds - C<ip:port>
99 110
100Nodes can only talk to each other by creating some kind of connection to 111Nodes can only talk to each other by creating some kind of connection to
101each other. To do this, nodes should listen on one or more local transport 112each other. To do this, nodes should listen on one or more local transport
113endpoints - binds.
114
102endpoints - binds. Currently, only standard C<ip:port> specifications can 115Currently, only standard C<ip:port> specifications can be used, which
103be used, which specify TCP ports to listen on. 116specify TCP ports to listen on. So a bind is basically just a tcp socket
117in listening mode thta accepts conenctions form other nodes.
104 118
119=item seed nodes
120
121When a node starts, it knows nothing about the network it is in - it
122needs to connect to at least one other node that is already in the
123network. These other nodes are called "seed nodes".
124
125Seed nodes themselves are not special - they are seed nodes only because
126some other node I<uses> them as such, but any node can be used as seed
127node for other nodes, and eahc node cna use a different set of seed nodes.
128
129In addition to discovering the network, seed nodes are also used to
130maintain the network - all nodes using the same seed node form are part of
131the same network. If a network is split into multiple subnets because e.g.
132the network link between the parts goes down, then using the same seed
133nodes for all nodes ensures that eventually the subnets get merged again.
134
135Seed nodes are expected to be long-running, and at least one seed node
136should always be available. They should also be relatively responsive - a
137seed node that blocks for long periods will slow down everybody else.
138
139For small networks, it's best if every node uses the same set of seed
140nodes. For large networks, it can be useful to specify "regional" seed
141nodes for most nodes in an area, and use all seed nodes as seed nodes for
142each other. What's important is that all seed nodes connections form a
143complete graph, so that the network cannot split into separate subnets
144forever.
145
146Seed nodes are represented by seed IDs.
147
105=item seeds - C<host:port> 148=item seed IDs - C<host:port>
106 149
107When a node starts, it knows nothing about the network. To teach the node 150Seed IDs are transport endpoint(s) (usually a hostname/IP address and a
108about the network it first has to contact some other node within the 151TCP port) of nodes that should be used as seed nodes.
109network. This node is called a seed.
110 152
111Seeds are transport endpoint(s) of as many nodes as one wants. Those nodes 153=item global nodes
112are expected to be long-running, and at least one of those should always
113be available. When nodes run out of connections (e.g. due to a network
114error), they try to re-establish connections to some seednodes again to
115join the network.
116 154
117Apart from being sued for seeding, seednodes are not special in any way - 155An AEMP network needs a discovery service - nodes need to know how to
118every public node can be a seednode. 156connect to other nodes they only know by name. In addition, AEMP offers a
157distributed "group database", which maps group names to a list of strings
158- for example, to register worker ports.
159
160A network needs at least one global node to work, and allows every node to
161be a global node.
162
163Any node that loads the L<AnyEvent::MP::Global> module becomes a global
164node and tries to keep connections to all other nodes. So while it can
165make sense to make every node "global" in small networks, it usually makes
166sense to only make seed nodes into global nodes in large networks (nodes
167keep connections to seed nodes and global nodes, so makign them the same
168reduces overhead).
119 169
120=back 170=back
121 171
122=head1 VARIABLES/FUNCTIONS 172=head1 VARIABLES/FUNCTIONS
123 173
125 175
126=cut 176=cut
127 177
128package AnyEvent::MP; 178package AnyEvent::MP;
129 179
180use AnyEvent::MP::Config ();
130use AnyEvent::MP::Kernel; 181use AnyEvent::MP::Kernel;
182use AnyEvent::MP::Kernel qw(%NODE %PORT %PORT_DATA $UNIQ $RUNIQ $ID);
131 183
132use common::sense; 184use common::sense;
133 185
134use Carp (); 186use Carp ();
135 187
136use AE (); 188use AE ();
137 189
138use base "Exporter"; 190use base "Exporter";
139 191
140our $VERSION = $AnyEvent::MP::Kernel::VERSION; 192our $VERSION = $AnyEvent::MP::Config::VERSION;
141 193
142our @EXPORT = qw( 194our @EXPORT = qw(
143 NODE $NODE *SELF node_of after 195 NODE $NODE *SELF node_of after
144 initialise_node 196 configure
145 snd rcv mon mon_guard kil reg psub spawn 197 snd rcv mon mon_guard kil psub peval spawn cal
146 port 198 port
147); 199);
148 200
149our $SELF; 201our $SELF;
150 202
156 208
157=item $thisnode = NODE / $NODE 209=item $thisnode = NODE / $NODE
158 210
159The C<NODE> function returns, and the C<$NODE> variable contains, the node 211The C<NODE> function returns, and the C<$NODE> variable contains, the node
160ID of the node running in the current process. This value is initialised by 212ID of the node running in the current process. This value is initialised by
161a call to C<initialise_node>. 213a call to C<configure>.
162 214
163=item $nodeid = node_of $port 215=item $nodeid = node_of $port
164 216
165Extracts and returns the node ID from a port ID or a node ID. 217Extracts and returns the node ID from a port ID or a node ID.
166 218
167=item initialise_node $profile_name 219=item configure $profile, key => value...
220
221=item configure key => value...
168 222
169Before a node can talk to other nodes on the network (i.e. enter 223Before a node can talk to other nodes on the network (i.e. enter
170"distributed mode") it has to initialise itself - the minimum a node needs 224"distributed mode") it has to configure itself - the minimum a node needs
171to know is its own name, and optionally it should know the addresses of 225to know is its own name, and optionally it should know the addresses of
172some other nodes in the network to discover other nodes. 226some other nodes in the network to discover other nodes.
173 227
174This function initialises a node - it must be called exactly once (or 228This function configures a node - it must be called exactly once (or
175never) before calling other AnyEvent::MP functions. 229never) before calling other AnyEvent::MP functions.
176 230
177The first argument is a profile name. If it is C<undef> or missing, then 231The key/value pairs are basically the same ones as documented for the
178the current nodename will be used instead (i.e. F<uname -n>). 232F<aemp> command line utility (sans the set/del prefix), with two additions:
179 233
234=over 4
235
236=item norc => $boolean (default false)
237
238If true, then the rc file (e.g. F<~/.perl-anyevent-mp>) will I<not>
239be consulted - all configuraiton options must be specified in the
240C<configure> call.
241
242=item force => $boolean (default false)
243
244IF true, then the values specified in the C<configure> will take
245precedence over any values configured via the rc file. The default is for
246the rc file to override any options specified in the program.
247
248=back
249
250=over 4
251
252=item step 1, gathering configuration from profiles
253
180The function then looks up the profile in the aemp configuration (see the 254The function first looks up a profile in the aemp configuration (see the
181L<aemp> commandline utility). 255L<aemp> commandline utility). The profile name can be specified via the
256named C<profile> parameter or can simply be the first parameter). If it is
257missing, then the nodename (F<uname -n>) will be used as profile name.
258
259The profile data is then gathered as follows:
260
261First, all remaining key => value pairs (all of which are conveniently
262undocumented at the moment) will be interpreted as configuration
263data. Then they will be overwritten by any values specified in the global
264default configuration (see the F<aemp> utility), then the chain of
265profiles chosen by the profile name (and any C<parent> attributes).
266
267That means that the values specified in the profile have highest priority
268and the values specified directly via C<configure> have lowest priority,
269and can only be used to specify defaults.
182 270
183If the profile specifies a node ID, then this will become the node ID of 271If the profile specifies a node ID, then this will become the node ID of
184this process. If not, then the profile name will be used as node ID. The 272this process. If not, then the profile name will be used as node ID. The
185special node ID of C<anon/> will be replaced by a random node ID. 273special node ID of C<anon/> will be replaced by a random node ID.
274
275=item step 2, bind listener sockets
186 276
187The next step is to look up the binds in the profile, followed by binding 277The next step is to look up the binds in the profile, followed by binding
188aemp protocol listeners on all binds specified (it is possible and valid 278aemp protocol listeners on all binds specified (it is possible and valid
189to have no binds, meaning that the node cannot be contacted form the 279to have no binds, meaning that the node cannot be contacted form the
190outside. This means the node cannot talk to other nodes that also have no 280outside. This means the node cannot talk to other nodes that also have no
191binds, but it can still talk to all "normal" nodes). 281binds, but it can still talk to all "normal" nodes).
192 282
193If the profile does not specify a binds list, then the node ID will be 283If the profile does not specify a binds list, then a default of C<*> is
194treated as if it were of the form C<host:port>, which will be resolved and 284used, meaning the node will bind on a dynamically-assigned port on every
195used as binds list. 285local IP address it finds.
196 286
287=item step 3, connect to seed nodes
288
197Lastly, the seeds list from the profile is passed to the 289As the last step, the seed ID list from the profile is passed to the
198L<AnyEvent::MP::Global> module, which will then use it to keep 290L<AnyEvent::MP::Global> module, which will then use it to keep
199connectivity with at least on of those seed nodes at any point in time. 291connectivity with at least one node at any point in time.
200 292
201Example: become a distributed node listening on the guessed noderef, or 293=back
202the one specified via C<aemp> for the current node. This should be the 294
295Example: become a distributed node using the local node name as profile.
203most common form of invocation for "daemon"-type nodes. 296This should be the most common form of invocation for "daemon"-type nodes.
204 297
205 initialise_node; 298 configure
206 299
207Example: become an anonymous node. This form is often used for commandline 300Example: become an anonymous node. This form is often used for commandline
208clients. 301clients.
209 302
210 initialise_node "anon/"; 303 configure nodeid => "anon/";
211 304
212Example: become a distributed node. If there is no profile of the given 305Example: configure a node using a profile called seed, which is suitable
213name, or no binds list was specified, resolve C<localhost:4044> and bind 306for a seed node as it binds on all local addresses on a fixed port (4040,
214on the resulting addresses. 307customary for aemp).
215 308
216 initialise_node "localhost:4044"; 309 # use the aemp commandline utility
310 # aemp profile seed nodeid anon/ binds '*:4040'
311
312 # then use it
313 configure profile => "seed";
314
315 # or simply use aemp from the shell again:
316 # aemp run profile seed
317
318 # or provide a nicer-to-remember nodeid
319 # aemp run profile seed nodeid "$(hostname)"
217 320
218=item $SELF 321=item $SELF
219 322
220Contains the current port id while executing C<rcv> callbacks or C<psub> 323Contains the current port id while executing C<rcv> callbacks or C<psub>
221blocks. 324blocks.
282sub _kilme { 385sub _kilme {
283 die "received message on port without callback"; 386 die "received message on port without callback";
284} 387}
285 388
286sub port(;&) { 389sub port(;&) {
287 my $id = "$UNIQ." . $ID++; 390 my $id = "$UNIQ." . ++$ID;
288 my $port = "$NODE#$id"; 391 my $port = "$NODE#$id";
289 392
290 rcv $port, shift || \&_kilme; 393 rcv $port, shift || \&_kilme;
291 394
292 $port 395 $port
331 msg1 => sub { ... }, 434 msg1 => sub { ... },
332 ... 435 ...
333 ; 436 ;
334 437
335Example: temporarily register a rcv callback for a tag matching some port 438Example: temporarily register a rcv callback for a tag matching some port
336(e.g. for a rpc reply) and unregister it after a message was received. 439(e.g. for an rpc reply) and unregister it after a message was received.
337 440
338 rcv $port, $otherport => sub { 441 rcv $port, $otherport => sub {
339 my @reply = @_; 442 my @reply = @_;
340 443
341 rcv $SELF, $otherport; 444 rcv $SELF, $otherport;
343 446
344=cut 447=cut
345 448
346sub rcv($@) { 449sub rcv($@) {
347 my $port = shift; 450 my $port = shift;
348 my ($noderef, $portid) = split /#/, $port, 2; 451 my ($nodeid, $portid) = split /#/, $port, 2;
349 452
350 $NODE{$noderef} == $NODE{""} 453 $NODE{$nodeid} == $NODE{""}
351 or Carp::croak "$port: rcv can only be called on local ports, caught"; 454 or Carp::croak "$port: rcv can only be called on local ports, caught";
352 455
353 while (@_) { 456 while (@_) {
354 if (ref $_[0]) { 457 if (ref $_[0]) {
355 if (my $self = $PORT_DATA{$portid}) { 458 if (my $self = $PORT_DATA{$portid}) {
356 "AnyEvent::MP::Port" eq ref $self 459 "AnyEvent::MP::Port" eq ref $self
357 or Carp::croak "$port: rcv can only be called on message matching ports, caught"; 460 or Carp::croak "$port: rcv can only be called on message matching ports, caught";
358 461
359 $self->[2] = shift; 462 $self->[0] = shift;
360 } else { 463 } else {
361 my $cb = shift; 464 my $cb = shift;
362 $PORT{$portid} = sub { 465 $PORT{$portid} = sub {
363 local $SELF = $port; 466 local $SELF = $port;
364 eval { &$cb }; _self_die if $@; 467 eval { &$cb }; _self_die if $@;
365 }; 468 };
366 } 469 }
367 } elsif (defined $_[0]) { 470 } elsif (defined $_[0]) {
368 my $self = $PORT_DATA{$portid} ||= do { 471 my $self = $PORT_DATA{$portid} ||= do {
369 my $self = bless [$PORT{$port} || sub { }, { }, $port], "AnyEvent::MP::Port"; 472 my $self = bless [$PORT{$portid} || sub { }, { }, $port], "AnyEvent::MP::Port";
370 473
371 $PORT{$portid} = sub { 474 $PORT{$portid} = sub {
372 local $SELF = $port; 475 local $SELF = $port;
373 476
374 if (my $cb = $self->[1]{$_[0]}) { 477 if (my $cb = $self->[1]{$_[0]}) {
396 } 499 }
397 500
398 $port 501 $port
399} 502}
400 503
504=item peval $port, $coderef[, @args]
505
506Evaluates the given C<$codref> within the contetx of C<$port>, that is,
507when the code throews an exception the C<$port> will be killed.
508
509Any remaining args will be passed to the callback. Any return values will
510be returned to the caller.
511
512This is useful when you temporarily want to execute code in the context of
513a port.
514
515Example: create a port and run some initialisation code in it's context.
516
517 my $port = port { ... };
518
519 peval $port, sub {
520 init
521 or die "unable to init";
522 };
523
524=cut
525
526sub peval($$) {
527 local $SELF = shift;
528 my $cb = shift;
529
530 if (wantarray) {
531 my @res = eval { &$cb };
532 _self_die if $@;
533 @res
534 } else {
535 my $res = eval { &$cb };
536 _self_die if $@;
537 $res
538 }
539}
540
401=item $closure = psub { BLOCK } 541=item $closure = psub { BLOCK }
402 542
403Remembers C<$SELF> and creates a closure out of the BLOCK. When the 543Remembers C<$SELF> and creates a closure out of the BLOCK. When the
404closure is executed, sets up the environment in the same way as in C<rcv> 544closure is executed, sets up the environment in the same way as in C<rcv>
405callbacks, i.e. runtime errors will cause the port to get C<kil>ed. 545callbacks, i.e. runtime errors will cause the port to get C<kil>ed.
546
547The effect is basically as if it returned C<< sub { peval $SELF, sub {
548BLOCK }, @_ } >>.
406 549
407This is useful when you register callbacks from C<rcv> callbacks: 550This is useful when you register callbacks from C<rcv> callbacks:
408 551
409 rcv delayed_reply => sub { 552 rcv delayed_reply => sub {
410 my ($delay, @reply) = @_; 553 my ($delay, @reply) = @_;
446 589
447Monitor the given port and do something when the port is killed or 590Monitor the given port and do something when the port is killed or
448messages to it were lost, and optionally return a guard that can be used 591messages to it were lost, and optionally return a guard that can be used
449to stop monitoring again. 592to stop monitoring again.
450 593
594In the first form (callback), the callback is simply called with any
595number of C<@reason> elements (no @reason means that the port was deleted
596"normally"). Note also that I<< the callback B<must> never die >>, so use
597C<eval> if unsure.
598
599In the second form (another port given), the other port (C<$rcvport>)
600will be C<kil>'ed with C<@reason>, if a @reason was specified, i.e. on
601"normal" kils nothing happens, while under all other conditions, the other
602port is killed with the same reason.
603
604The third form (kill self) is the same as the second form, except that
605C<$rvport> defaults to C<$SELF>.
606
607In the last form (message), a message of the form C<@msg, @reason> will be
608C<snd>.
609
610Monitoring-actions are one-shot: once messages are lost (and a monitoring
611alert was raised), they are removed and will not trigger again.
612
613As a rule of thumb, monitoring requests should always monitor a port from
614a local port (or callback). The reason is that kill messages might get
615lost, just like any other message. Another less obvious reason is that
616even monitoring requests can get lost (for example, when the connection
617to the other node goes down permanently). When monitoring a port locally
618these problems do not exist.
619
451C<mon> effectively guarantees that, in the absence of hardware failures, 620C<mon> effectively guarantees that, in the absence of hardware failures,
452after starting the monitor, either all messages sent to the port will 621after starting the monitor, either all messages sent to the port will
453arrive, or the monitoring action will be invoked after possible message 622arrive, or the monitoring action will be invoked after possible message
454loss has been detected. No messages will be lost "in between" (after 623loss has been detected. No messages will be lost "in between" (after
455the first lost message no further messages will be received by the 624the first lost message no further messages will be received by the
456port). After the monitoring action was invoked, further messages might get 625port). After the monitoring action was invoked, further messages might get
457delivered again. 626delivered again.
458 627
459Note that monitoring-actions are one-shot: once messages are lost (and a 628Inter-host-connection timeouts and monitoring depend on the transport
460monitoring alert was raised), they are removed and will not trigger again. 629used. The only transport currently implemented is TCP, and AnyEvent::MP
630relies on TCP to detect node-downs (this can take 10-15 minutes on a
631non-idle connection, and usually around two hours for idle connections).
461 632
462In the first form (callback), the callback is simply called with any 633This means that monitoring is good for program errors and cleaning up
463number of C<@reason> elements (no @reason means that the port was deleted 634stuff eventually, but they are no replacement for a timeout when you need
464"normally"). Note also that I<< the callback B<must> never die >>, so use 635to ensure some maximum latency.
465C<eval> if unsure.
466
467In the second form (another port given), the other port (C<$rcvport>)
468will be C<kil>'ed with C<@reason>, iff a @reason was specified, i.e. on
469"normal" kils nothing happens, while under all other conditions, the other
470port is killed with the same reason.
471
472The third form (kill self) is the same as the second form, except that
473C<$rvport> defaults to C<$SELF>.
474
475In the last form (message), a message of the form C<@msg, @reason> will be
476C<snd>.
477
478As a rule of thumb, monitoring requests should always monitor a port from
479a local port (or callback). The reason is that kill messages might get
480lost, just like any other message. Another less obvious reason is that
481even monitoring requests can get lost (for exmaple, when the connection
482to the other node goes down permanently). When monitoring a port locally
483these problems do not exist.
484 636
485Example: call a given callback when C<$port> is killed. 637Example: call a given callback when C<$port> is killed.
486 638
487 mon $port, sub { warn "port died because of <@_>\n" }; 639 mon $port, sub { warn "port died because of <@_>\n" };
488 640
495 mon $port, $self => "restart"; 647 mon $port, $self => "restart";
496 648
497=cut 649=cut
498 650
499sub mon { 651sub mon {
500 my ($noderef, $port) = split /#/, shift, 2; 652 my ($nodeid, $port) = split /#/, shift, 2;
501 653
502 my $node = $NODE{$noderef} || add_node $noderef; 654 my $node = $NODE{$nodeid} || add_node $nodeid;
503 655
504 my $cb = @_ ? shift : $SELF || Carp::croak 'mon: called with one argument only, but $SELF not set,'; 656 my $cb = @_ ? shift : $SELF || Carp::croak 'mon: called with one argument only, but $SELF not set,';
505 657
506 unless (ref $cb) { 658 unless (ref $cb) {
507 if (@_) { 659 if (@_) {
516 } 668 }
517 669
518 $node->monitor ($port, $cb); 670 $node->monitor ($port, $cb);
519 671
520 defined wantarray 672 defined wantarray
521 and AnyEvent::Util::guard { $node->unmonitor ($port, $cb) } 673 and ($cb += 0, AnyEvent::Util::guard { $node->unmonitor ($port, $cb) })
522} 674}
523 675
524=item $guard = mon_guard $port, $ref, $ref... 676=item $guard = mon_guard $port, $ref, $ref...
525 677
526Monitors the given C<$port> and keeps the passed references. When the port 678Monitors the given C<$port> and keeps the passed references. When the port
549 701
550=item kil $port[, @reason] 702=item kil $port[, @reason]
551 703
552Kill the specified port with the given C<@reason>. 704Kill the specified port with the given C<@reason>.
553 705
554If no C<@reason> is specified, then the port is killed "normally" (ports 706If no C<@reason> is specified, then the port is killed "normally" -
555monitoring other ports will not necessarily die because a port dies 707monitor callback will be invoked, but the kil will not cause linked ports
556"normally"). 708(C<mon $mport, $lport> form) to get killed.
557 709
558Otherwise, linked ports get killed with the same reason (second form of 710If a C<@reason> is specified, then linked ports (C<mon $mport, $lport>
559C<mon>, see above). 711form) get killed with the same reason.
560 712
561Runtime errors while evaluating C<rcv> callbacks or inside C<psub> blocks 713Runtime errors while evaluating C<rcv> callbacks or inside C<psub> blocks
562will be reported as reason C<< die => $@ >>. 714will be reported as reason C<< die => $@ >>.
563 715
564Transport/communication errors are reported as C<< transport_error => 716Transport/communication errors are reported as C<< transport_error =>
583the package, then the package above the package and so on (e.g. 735the package, then the package above the package and so on (e.g.
584C<MyApp::Chat::Server>, C<MyApp::Chat>, C<MyApp>) until the function 736C<MyApp::Chat::Server>, C<MyApp::Chat>, C<MyApp>) until the function
585exists or it runs out of package names. 737exists or it runs out of package names.
586 738
587The init function is then called with the newly-created port as context 739The init function is then called with the newly-created port as context
588object (C<$SELF>) and the C<@initdata> values as arguments. 740object (C<$SELF>) and the C<@initdata> values as arguments. It I<must>
741call one of the C<rcv> functions to set callbacks on C<$SELF>, otherwise
742the port might not get created.
589 743
590A common idiom is to pass a local port, immediately monitor the spawned 744A common idiom is to pass a local port, immediately monitor the spawned
591port, and in the remote init function, immediately monitor the passed 745port, and in the remote init function, immediately monitor the passed
592local port. This two-way monitoring ensures that both ports get cleaned up 746local port. This two-way monitoring ensures that both ports get cleaned up
593when there is a problem. 747when there is a problem.
594 748
749C<spawn> guarantees that the C<$initfunc> has no visible effects on the
750caller before C<spawn> returns (by delaying invocation when spawn is
751called for the local node).
752
595Example: spawn a chat server port on C<$othernode>. 753Example: spawn a chat server port on C<$othernode>.
596 754
597 # this node, executed from within a port context: 755 # this node, executed from within a port context:
598 my $server = spawn $othernode, "MyApp::Chat::Server::connect", $SELF; 756 my $server = spawn $othernode, "MyApp::Chat::Server::connect", $SELF;
599 mon $server; 757 mon $server;
613 771
614sub _spawn { 772sub _spawn {
615 my $port = shift; 773 my $port = shift;
616 my $init = shift; 774 my $init = shift;
617 775
776 # rcv will create the actual port
618 local $SELF = "$NODE#$port"; 777 local $SELF = "$NODE#$port";
619 eval { 778 eval {
620 &{ load_func $init } 779 &{ load_func $init }
621 }; 780 };
622 _self_die if $@; 781 _self_die if $@;
623} 782}
624 783
625sub spawn(@) { 784sub spawn(@) {
626 my ($noderef, undef) = split /#/, shift, 2; 785 my ($nodeid, undef) = split /#/, shift, 2;
627 786
628 my $id = "$RUNIQ." . $ID++; 787 my $id = "$RUNIQ." . ++$ID;
629 788
630 $_[0] =~ /::/ 789 $_[0] =~ /::/
631 or Carp::croak "spawn init function must be a fully-qualified name, caught"; 790 or Carp::croak "spawn init function must be a fully-qualified name, caught";
632 791
633 snd_to_func $noderef, "AnyEvent::MP::_spawn" => $id, @_; 792 snd_to_func $nodeid, "AnyEvent::MP::_spawn" => $id, @_;
634 793
635 "$noderef#$id" 794 "$nodeid#$id"
636} 795}
796
637 797
638=item after $timeout, @msg 798=item after $timeout, @msg
639 799
640=item after $timeout, $callback 800=item after $timeout, $callback
641 801
657 ? $action[0]() 817 ? $action[0]()
658 : snd @action; 818 : snd @action;
659 }; 819 };
660} 820}
661 821
822=item cal $port, @msg, $callback[, $timeout]
823
824A simple form of RPC - sends a message to the given C<$port> with the
825given contents (C<@msg>), but adds a reply port to the message.
826
827The reply port is created temporarily just for the purpose of receiving
828the reply, and will be C<kil>ed when no longer needed.
829
830A reply message sent to the port is passed to the C<$callback> as-is.
831
832If an optional time-out (in seconds) is given and it is not C<undef>,
833then the callback will be called without any arguments after the time-out
834elapsed and the port is C<kil>ed.
835
836If no time-out is given (or it is C<undef>), then the local port will
837monitor the remote port instead, so it eventually gets cleaned-up.
838
839Currently this function returns the temporary port, but this "feature"
840might go in future versions unless you can make a convincing case that
841this is indeed useful for something.
842
843=cut
844
845sub cal(@) {
846 my $timeout = ref $_[-1] ? undef : pop;
847 my $cb = pop;
848
849 my $port = port {
850 undef $timeout;
851 kil $SELF;
852 &$cb;
853 };
854
855 if (defined $timeout) {
856 $timeout = AE::timer $timeout, 0, sub {
857 undef $timeout;
858 kil $port;
859 $cb->();
860 };
861 } else {
862 mon $_[0], sub {
863 kil $port;
864 $cb->();
865 };
866 }
867
868 push @_, $port;
869 &snd;
870
871 $port
872}
873
662=back 874=back
663 875
664=head1 AnyEvent::MP vs. Distributed Erlang 876=head1 AnyEvent::MP vs. Distributed Erlang
665 877
666AnyEvent::MP got lots of its ideas from distributed Erlang (Erlang node 878AnyEvent::MP got lots of its ideas from distributed Erlang (Erlang node
667== aemp node, Erlang process == aemp port), so many of the documents and 879== aemp node, Erlang process == aemp port), so many of the documents and
668programming techniques employed by Erlang apply to AnyEvent::MP. Here is a 880programming techniques employed by Erlang apply to AnyEvent::MP. Here is a
669sample: 881sample:
670 882
671 http://www.Erlang.se/doc/programming_rules.shtml 883 http://www.erlang.se/doc/programming_rules.shtml
672 http://Erlang.org/doc/getting_started/part_frame.html # chapters 3 and 4 884 http://erlang.org/doc/getting_started/part_frame.html # chapters 3 and 4
673 http://Erlang.org/download/Erlang-book-part1.pdf # chapters 5 and 6 885 http://erlang.org/download/erlang-book-part1.pdf # chapters 5 and 6
674 http://Erlang.org/download/armstrong_thesis_2003.pdf # chapters 4 and 5 886 http://erlang.org/download/armstrong_thesis_2003.pdf # chapters 4 and 5
675 887
676Despite the similarities, there are also some important differences: 888Despite the similarities, there are also some important differences:
677 889
678=over 4 890=over 4
679 891
680=item * Node IDs are arbitrary strings in AEMP. 892=item * Node IDs are arbitrary strings in AEMP.
681 893
682Erlang relies on special naming and DNS to work everywhere in the same 894Erlang relies on special naming and DNS to work everywhere in the same
683way. AEMP relies on each node somehow knowing its own address(es) (e.g. by 895way. AEMP relies on each node somehow knowing its own address(es) (e.g. by
684configuraiton or DNS), but will otherwise discover other odes itself. 896configuration or DNS), and possibly the addresses of some seed nodes, but
897will otherwise discover other nodes (and their IDs) itself.
685 898
686=item * Erlang has a "remote ports are like local ports" philosophy, AEMP 899=item * Erlang has a "remote ports are like local ports" philosophy, AEMP
687uses "local ports are like remote ports". 900uses "local ports are like remote ports".
688 901
689The failure modes for local ports are quite different (runtime errors 902The failure modes for local ports are quite different (runtime errors
698ports being the special case/exception, where transport errors cannot 911ports being the special case/exception, where transport errors cannot
699occur. 912occur.
700 913
701=item * Erlang uses processes and a mailbox, AEMP does not queue. 914=item * Erlang uses processes and a mailbox, AEMP does not queue.
702 915
703Erlang uses processes that selectively receive messages, and therefore 916Erlang uses processes that selectively receive messages out of order, and
704needs a queue. AEMP is event based, queuing messages would serve no 917therefore needs a queue. AEMP is event based, queuing messages would serve
705useful purpose. For the same reason the pattern-matching abilities of 918no useful purpose. For the same reason the pattern-matching abilities
706AnyEvent::MP are more limited, as there is little need to be able to 919of AnyEvent::MP are more limited, as there is little need to be able to
707filter messages without dequeing them. 920filter messages without dequeuing them.
708 921
709(But see L<Coro::MP> for a more Erlang-like process model on top of AEMP). 922This is not a philosophical difference, but simply stems from AnyEvent::MP
923being event-based, while Erlang is process-based.
924
925You cna have a look at L<Coro::MP> for a more Erlang-like process model on
926top of AEMP and Coro threads.
710 927
711=item * Erlang sends are synchronous, AEMP sends are asynchronous. 928=item * Erlang sends are synchronous, AEMP sends are asynchronous.
712 929
713Sending messages in Erlang is synchronous and blocks the process (and 930Sending messages in Erlang is synchronous and blocks the process until
931a conenction has been established and the message sent (and so does not
714so does not need a queue that can overflow). AEMP sends are immediate, 932need a queue that can overflow). AEMP sends return immediately, connection
715connection establishment is handled in the background. 933establishment is handled in the background.
716 934
717=item * Erlang suffers from silent message loss, AEMP does not. 935=item * Erlang suffers from silent message loss, AEMP does not.
718 936
719Erlang makes few guarantees on messages delivery - messages can get lost 937Erlang implements few guarantees on messages delivery - messages can get
720without any of the processes realising it (i.e. you send messages a, b, 938lost without any of the processes realising it (i.e. you send messages a,
721and c, and the other side only receives messages a and c). 939b, and c, and the other side only receives messages a and c).
722 940
723AEMP guarantees correct ordering, and the guarantee that after one message 941AEMP guarantees (modulo hardware errors) correct ordering, and the
724is lost, all following ones sent to the same port are lost as well, until 942guarantee that after one message is lost, all following ones sent to the
725monitoring raises an error, so there are no silent "holes" in the message 943same port are lost as well, until monitoring raises an error, so there are
726sequence. 944no silent "holes" in the message sequence.
945
946If you want your software to be very reliable, you have to cope with
947corrupted and even out-of-order messages in both Erlang and AEMP. AEMP
948simply tries to work better in common error cases, such as when a network
949link goes down.
727 950
728=item * Erlang can send messages to the wrong port, AEMP does not. 951=item * Erlang can send messages to the wrong port, AEMP does not.
729 952
730In Erlang it is quite likely that a node that restarts reuses a process ID 953In Erlang it is quite likely that a node that restarts reuses an Erlang
731known to other nodes for a completely different process, causing messages 954process ID known to other nodes for a completely different process,
732destined for that process to end up in an unrelated process. 955causing messages destined for that process to end up in an unrelated
956process.
733 957
734AEMP never reuses port IDs, so old messages or old port IDs floating 958AEMP does not reuse port IDs, so old messages or old port IDs floating
735around in the network will not be sent to an unrelated port. 959around in the network will not be sent to an unrelated port.
736 960
737=item * Erlang uses unprotected connections, AEMP uses secure 961=item * Erlang uses unprotected connections, AEMP uses secure
738authentication and can use TLS. 962authentication and can use TLS.
739 963
742 966
743=item * The AEMP protocol is optimised for both text-based and binary 967=item * The AEMP protocol is optimised for both text-based and binary
744communications. 968communications.
745 969
746The AEMP protocol, unlike the Erlang protocol, supports both programming 970The AEMP protocol, unlike the Erlang protocol, supports both programming
747language independent text-only protocols (good for debugging) and binary, 971language independent text-only protocols (good for debugging), and binary,
748language-specific serialisers (e.g. Storable). By default, unless TLS is 972language-specific serialisers (e.g. Storable). By default, unless TLS is
749used, the protocol is actually completely text-based. 973used, the protocol is actually completely text-based.
750 974
751It has also been carefully designed to be implementable in other languages 975It has also been carefully designed to be implementable in other languages
752with a minimum of work while gracefully degrading functionality to make the 976with a minimum of work while gracefully degrading functionality to make the
753protocol simple. 977protocol simple.
754 978
755=item * AEMP has more flexible monitoring options than Erlang. 979=item * AEMP has more flexible monitoring options than Erlang.
756 980
757In Erlang, you can chose to receive I<all> exit signals as messages 981In Erlang, you can chose to receive I<all> exit signals as messages or
758or I<none>, there is no in-between, so monitoring single processes is 982I<none>, there is no in-between, so monitoring single Erlang processes is
759difficult to implement. Monitoring in AEMP is more flexible than in 983difficult to implement.
760Erlang, as one can choose between automatic kill, exit message or callback 984
761on a per-process basis. 985Monitoring in AEMP is more flexible than in Erlang, as one can choose
986between automatic kill, exit message or callback on a per-port basis.
762 987
763=item * Erlang tries to hide remote/local connections, AEMP does not. 988=item * Erlang tries to hide remote/local connections, AEMP does not.
764 989
765Monitoring in Erlang is not an indicator of process death/crashes, in the 990Monitoring in Erlang is not an indicator of process death/crashes, in the
766same way as linking is (except linking is unreliable in Erlang). 991same way as linking is (except linking is unreliable in Erlang).
788overhead, as well as having to keep a proxy object everywhere. 1013overhead, as well as having to keep a proxy object everywhere.
789 1014
790Strings can easily be printed, easily serialised etc. and need no special 1015Strings can easily be printed, easily serialised etc. and need no special
791procedures to be "valid". 1016procedures to be "valid".
792 1017
793And as a result, a miniport consists of a single closure stored in a 1018And as a result, a port with just a default receiver consists of a single
794global hash - it can't become much cheaper. 1019code reference stored in a global hash - it can't become much cheaper.
795 1020
796=item Why favour JSON, why not a real serialising format such as Storable? 1021=item Why favour JSON, why not a real serialising format such as Storable?
797 1022
798In fact, any AnyEvent::MP node will happily accept Storable as framing 1023In fact, any AnyEvent::MP node will happily accept Storable as framing
799format, but currently there is no way to make a node use Storable by 1024format, but currently there is no way to make a node use Storable by
811 1036
812=back 1037=back
813 1038
814=head1 SEE ALSO 1039=head1 SEE ALSO
815 1040
1041L<AnyEvent::MP::Intro> - a gentle introduction.
1042
1043L<AnyEvent::MP::Kernel> - more, lower-level, stuff.
1044
1045L<AnyEvent::MP::Global> - network maintenance and port groups, to find
1046your applications.
1047
1048L<AnyEvent::MP::DataConn> - establish data connections between nodes.
1049
1050L<AnyEvent::MP::LogCatcher> - simple service to display log messages from
1051all nodes.
1052
816L<AnyEvent>. 1053L<AnyEvent>.
817 1054
818=head1 AUTHOR 1055=head1 AUTHOR
819 1056
820 Marc Lehmann <schmorp@schmorp.de> 1057 Marc Lehmann <schmorp@schmorp.de>

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines