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.71 by root, Sun Aug 30 19:52:56 2009 UTC vs.
Revision 1.138 by root, Thu Mar 22 00:48:29 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 $port, $cb->(@msg) # callback is invoked on death
38 mon $port, $otherport # kill otherport on abnormal death 41 mon $port, $localport # kill localport on abnormal death
39 mon $port, $otherport, @msg # send message on death 42 mon $port, $localport, @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
43 bin/aemp - stable. 54 bin/aemp - stable.
44 AnyEvent::MP - stable API, should work. 55 AnyEvent::MP - stable API, should work.
45 AnyEvent::MP::Intro - uptodate, but incomplete. 56 AnyEvent::MP::Intro - explains most concepts.
46 AnyEvent::MP::Kernel - mostly stable. 57 AnyEvent::MP::Kernel - mostly stable API.
47 AnyEvent::MP::Global - stable API, protocol not yet final. 58 AnyEvent::MP::Global - stable API.
48
49 stay tuned.
50 59
51=head1 DESCRIPTION 60=head1 DESCRIPTION
52 61
53This module (-family) implements a simple message passing framework. 62This module (-family) implements a simple message passing framework.
54 63
56on the same or other hosts, and you can supervise entities remotely. 65on the same or other hosts, and you can supervise entities remotely.
57 66
58For 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>
59manual page and the examples under F<eg/>. 68manual page and the examples under F<eg/>.
60 69
61At the moment, this module family is a bit underdocumented.
62
63=head1 CONCEPTS 70=head1 CONCEPTS
64 71
65=over 4 72=over 4
66 73
67=item port 74=item port
68 75
69A 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).
70 78
71Ports 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
72some messages. Messages send to ports will not be queued, regardless of 80some messages. Messages send to ports will not be queued, regardless of
73anything was listening for them or not. 81anything was listening for them or not.
74 82
83Ports are represented by (printable) strings called "port IDs".
84
75=item port ID - C<nodeid#portname> 85=item port ID - C<nodeid#portname>
76 86
77A 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<#>)
78separator, and a port name (a printable string of unspecified format). 88as separator, and a port name (a printable string of unspecified
89format created by AnyEvent::MP).
79 90
80=item node 91=item node
81 92
82A node is a single process containing at least one port - the node port, 93A node is a single process containing at least one port - the node port,
83which enables nodes to manage each other remotely, and to create new 94which enables nodes to manage each other remotely, and to create new
84ports. 95ports.
85 96
86Nodes are either public (have one or more listening ports) or private 97Nodes are either public (have one or more listening ports) or private
87(no listening ports). Private nodes cannot talk to other private nodes 98(no listening ports). Private nodes cannot talk to other private nodes
88currently. 99currently, but all nodes can talk to public nodes.
89 100
101Nodes is represented by (printable) strings called "node IDs".
102
90=item node ID - C<[a-za-Z0-9_\-.:]+> 103=item node ID - C<[A-Za-z0-9_\-.:]*>
91 104
92A node ID is a string that uniquely identifies the node within a 105A node ID is a string that uniquely identifies the node within a
93network. Depending on the configuration used, node IDs can look like a 106network. Depending on the configuration used, node IDs can look like a
94hostname, a hostname and a port, or a random string. AnyEvent::MP itself 107hostname, a hostname and a port, or a random string. AnyEvent::MP itself
95doesn't interpret node IDs in any way. 108doesn't interpret node IDs in any way except to uniquely identify a node.
96 109
97=item binds - C<ip:port> 110=item binds - C<ip:port>
98 111
99Nodes can only talk to each other by creating some kind of connection to 112Nodes can only talk to each other by creating some kind of connection to
100each other. To do this, nodes should listen on one or more local transport 113each other. To do this, nodes should listen on one or more local transport
114endpoints - binds.
115
101endpoints - binds. Currently, only standard C<ip:port> specifications can 116Currently, only standard C<ip:port> specifications can be used, which
102be used, which specify TCP ports to listen on. 117specify TCP ports to listen on. So a bind is basically just a tcp socket
118in listening mode thta accepts conenctions form other nodes.
103 119
120=item seed nodes
121
122When a node starts, it knows nothing about the network it is in - it
123needs to connect to at least one other node that is already in the
124network. These other nodes are called "seed nodes".
125
126Seed nodes themselves are not special - they are seed nodes only because
127some other node I<uses> them as such, but any node can be used as seed
128node for other nodes, and eahc node cna use a different set of seed nodes.
129
130In addition to discovering the network, seed nodes are also used to
131maintain the network - all nodes using the same seed node form are part of
132the same network. If a network is split into multiple subnets because e.g.
133the network link between the parts goes down, then using the same seed
134nodes for all nodes ensures that eventually the subnets get merged again.
135
136Seed nodes are expected to be long-running, and at least one seed node
137should always be available. They should also be relatively responsive - a
138seed node that blocks for long periods will slow down everybody else.
139
140For small networks, it's best if every node uses the same set of seed
141nodes. For large networks, it can be useful to specify "regional" seed
142nodes for most nodes in an area, and use all seed nodes as seed nodes for
143each other. What's important is that all seed nodes connections form a
144complete graph, so that the network cannot split into separate subnets
145forever.
146
147Seed nodes are represented by seed IDs.
148
104=item seeds - C<host:port> 149=item seed IDs - C<host:port>
105 150
106When a node starts, it knows nothing about the network. To teach the node 151Seed IDs are transport endpoint(s) (usually a hostname/IP address and a
107about the network it first has to contact some other node within the 152TCP port) of nodes that should be used as seed nodes.
108network. This node is called a seed.
109 153
110Seeds are transport endpoint(s) of as many nodes as one wants. Those nodes 154=item global nodes
111are expected to be long-running, and at least one of those should always
112be available. When nodes run out of connections (e.g. due to a network
113error), they try to re-establish connections to some seednodes again to
114join the network.
115 155
116Apart from being sued for seeding, seednodes are not special in any way - 156An AEMP network needs a discovery service - nodes need to know how to
117every public node can be a seednode. 157connect to other nodes they only know by name. In addition, AEMP offers a
158distributed "group database", which maps group names to a list of strings
159- for example, to register worker ports.
160
161A network needs at least one global node to work, and allows every node to
162be a global node.
163
164Any node that loads the L<AnyEvent::MP::Global> module becomes a global
165node and tries to keep connections to all other nodes. So while it can
166make sense to make every node "global" in small networks, it usually makes
167sense to only make seed nodes into global nodes in large networks (nodes
168keep connections to seed nodes and global nodes, so makign them the same
169reduces overhead).
118 170
119=back 171=back
120 172
121=head1 VARIABLES/FUNCTIONS 173=head1 VARIABLES/FUNCTIONS
122 174
124 176
125=cut 177=cut
126 178
127package AnyEvent::MP; 179package AnyEvent::MP;
128 180
181use AnyEvent::MP::Config ();
129use AnyEvent::MP::Kernel; 182use AnyEvent::MP::Kernel;
183use AnyEvent::MP::Kernel qw(%NODE %PORT %PORT_DATA $UNIQ $RUNIQ $ID);
130 184
131use common::sense; 185use common::sense;
132 186
133use Carp (); 187use Carp ();
134 188
135use AE (); 189use AE ();
190use Guard ();
136 191
137use base "Exporter"; 192use base "Exporter";
138 193
139our $VERSION = $AnyEvent::MP::Kernel::VERSION; 194our $VERSION = $AnyEvent::MP::Config::VERSION;
140 195
141our @EXPORT = qw( 196our @EXPORT = qw(
142 NODE $NODE *SELF node_of after 197 NODE $NODE *SELF node_of after
143 initialise_node 198 configure
144 snd rcv mon mon_guard kil reg psub spawn 199 snd rcv mon mon_guard kil psub peval spawn cal
145 port 200 port
201 db_set db_del db_reg
202 db_mon db_family db_keys db_values
146); 203);
147 204
148our $SELF; 205our $SELF;
149 206
150sub _self_die() { 207sub _self_die() {
155 212
156=item $thisnode = NODE / $NODE 213=item $thisnode = NODE / $NODE
157 214
158The C<NODE> function returns, and the C<$NODE> variable contains, the node 215The C<NODE> function returns, and the C<$NODE> variable contains, the node
159ID of the node running in the current process. This value is initialised by 216ID of the node running in the current process. This value is initialised by
160a call to C<initialise_node>. 217a call to C<configure>.
161 218
162=item $nodeid = node_of $port 219=item $nodeid = node_of $port
163 220
164Extracts and returns the node ID from a port ID or a node ID. 221Extracts and returns the node ID from a port ID or a node ID.
165 222
166=item initialise_node $profile_name, key => value... 223=item configure $profile, key => value...
224
225=item configure key => value...
167 226
168Before a node can talk to other nodes on the network (i.e. enter 227Before a node can talk to other nodes on the network (i.e. enter
169"distributed mode") it has to initialise itself - the minimum a node needs 228"distributed mode") it has to configure itself - the minimum a node needs
170to know is its own name, and optionally it should know the addresses of 229to know is its own name, and optionally it should know the addresses of
171some other nodes in the network to discover other nodes. 230some other nodes in the network to discover other nodes.
172 231
173This function initialises a node - it must be called exactly once (or 232This function configures a node - it must be called exactly once (or
174never) before calling other AnyEvent::MP functions. 233never) before calling other AnyEvent::MP functions.
175 234
176The first argument is a profile name. If it is C<undef> or missing, then 235The key/value pairs are basically the same ones as documented for the
177the current nodename will be used instead (i.e. F<uname -n>). 236F<aemp> command line utility (sans the set/del prefix), with these additions:
178 237
238=over 4
239
240=item norc => $boolean (default false)
241
242If true, then the rc file (e.g. F<~/.perl-anyevent-mp>) will I<not>
243be consulted - all configuraiton options must be specified in the
244C<configure> call.
245
246=item force => $boolean (default false)
247
248IF true, then the values specified in the C<configure> will take
249precedence over any values configured via the rc file. The default is for
250the rc file to override any options specified in the program.
251
252=item secure => $pass->(@msg)
253
254In addition to specifying a boolean, you can specify a code reference that
255is called for every code execution attempt - the execution request is
256granted iff the callback returns a true value.
257
258Most of the time the callback should look only at
259C<$AnyEvent::MP::Kernel::SRCNODE> to make a decision, and not at the
260actual message (which can be about anything, and is mostly provided for
261diagnostic purposes).
262
263See F<semp setsecure> for more info.
264
265=back
266
267=over 4
268
269=item step 1, gathering configuration from profiles
270
179The function first looks up the profile in the aemp configuration (see the 271The function first looks up a profile in the aemp configuration (see the
180L<aemp> commandline utility). the profile is calculated as follows: 272L<aemp> commandline utility). The profile name can be specified via the
273named C<profile> parameter or can simply be the first parameter). If it is
274missing, then the nodename (F<uname -n>) will be used as profile name.
181 275
276The profile data is then gathered as follows:
277
182First, all remaining key => value pairs (all of which are conviniently 278First, all remaining key => value pairs (all of which are conveniently
183undocumented at the moment) will be used. Then they will be overwritten by 279undocumented at the moment) will be interpreted as configuration
184any values specified in the global default configuration (see the F<aemp> 280data. Then they will be overwritten by any values specified in the global
185utility), then the chain of profiles selected, if any. That means that 281default configuration (see the F<aemp> utility), then the chain of
282profiles chosen by the profile name (and any C<parent> attributes).
283
186the values specified in the profile have highest priority and the values 284That means that the values specified in the profile have highest priority
187specified via C<initialise_node> have lowest priority. 285and the values specified directly via C<configure> have lowest priority,
286and can only be used to specify defaults.
188 287
189If the profile specifies a node ID, then this will become the node ID of 288If the profile specifies a node ID, then this will become the node ID of
190this process. If not, then the profile name will be used as node ID. The 289this process. If not, then the profile name will be used as node ID, with
191special node ID of C<anon/> will be replaced by a random node ID. 290a unique randoms tring (C</%u>) appended.
291
292The node ID can contain some C<%> sequences that are expanded: C<%n>
293is expanded to the local nodename, C<%u> is replaced by a random
294strign to make the node unique. For example, the F<aemp> commandline
295utility uses C<aemp/%n/%u> as nodename, which might expand to
296C<aemp/cerebro/ZQDGSIkRhEZQDGSIkRhE>.
297
298=item step 2, bind listener sockets
192 299
193The next step is to look up the binds in the profile, followed by binding 300The next step is to look up the binds in the profile, followed by binding
194aemp protocol listeners on all binds specified (it is possible and valid 301aemp protocol listeners on all binds specified (it is possible and valid
195to have no binds, meaning that the node cannot be contacted form the 302to have no binds, meaning that the node cannot be contacted form the
196outside. This means the node cannot talk to other nodes that also have no 303outside. This means the node cannot talk to other nodes that also have no
197binds, but it can still talk to all "normal" nodes). 304binds, but it can still talk to all "normal" nodes).
198 305
199If the profile does not specify a binds list, then a default of C<*> is 306If the profile does not specify a binds list, then a default of C<*> is
200used. 307used, meaning the node will bind on a dynamically-assigned port on every
308local IP address it finds.
201 309
310=item step 3, connect to seed nodes
311
202Lastly, the seeds list from the profile is passed to the 312As the last step, the seed ID list from the profile is passed to the
203L<AnyEvent::MP::Global> module, which will then use it to keep 313L<AnyEvent::MP::Global> module, which will then use it to keep
204connectivity with at least on of those seed nodes at any point in time. 314connectivity with at least one node at any point in time.
205 315
206Example: become a distributed node listening on the guessed noderef, or 316=back
207the one specified via C<aemp> for the current node. This should be the 317
318Example: become a distributed node using the local node name as profile.
208most common form of invocation for "daemon"-type nodes. 319This should be the most common form of invocation for "daemon"-type nodes.
209 320
210 initialise_node; 321 configure
211 322
212Example: become an anonymous node. This form is often used for commandline 323Example: become a semi-anonymous node. This form is often used for
213clients. 324commandline clients.
214 325
215 initialise_node "anon/"; 326 configure nodeid => "myscript/%n/%u";
216 327
217Example: become a distributed node. If there is no profile of the given 328Example: configure a node using a profile called seed, which is suitable
218name, or no binds list was specified, resolve C<localhost:4044> and bind 329for a seed node as it binds on all local addresses on a fixed port (4040,
219on the resulting addresses. 330customary for aemp).
220 331
221 initialise_node "localhost:4044"; 332 # use the aemp commandline utility
333 # aemp profile seed binds '*:4040'
334
335 # then use it
336 configure profile => "seed";
337
338 # or simply use aemp from the shell again:
339 # aemp run profile seed
340
341 # or provide a nicer-to-remember nodeid
342 # aemp run profile seed nodeid "$(hostname)"
222 343
223=item $SELF 344=item $SELF
224 345
225Contains the current port id while executing C<rcv> callbacks or C<psub> 346Contains the current port id while executing C<rcv> callbacks or C<psub>
226blocks. 347blocks.
282 403
283=cut 404=cut
284 405
285sub rcv($@); 406sub rcv($@);
286 407
287sub _kilme { 408my $KILME = sub {
288 die "received message on port without callback"; 409 (my $tag = substr $_[0], 0, 30) =~ s/([\x20-\x7e])/./g;
289} 410 kil $SELF, unhandled_message => "no callback found for message '$tag'";
411};
290 412
291sub port(;&) { 413sub port(;&) {
292 my $id = "$UNIQ." . $ID++; 414 my $id = $UNIQ . ++$ID;
293 my $port = "$NODE#$id"; 415 my $port = "$NODE#$id";
294 416
295 rcv $port, shift || \&_kilme; 417 rcv $port, shift || $KILME;
296 418
297 $port 419 $port
298} 420}
299 421
300=item rcv $local_port, $callback->(@msg) 422=item rcv $local_port, $callback->(@msg)
305 427
306The global C<$SELF> (exported by this module) contains C<$port> while 428The global C<$SELF> (exported by this module) contains C<$port> while
307executing the callback. Runtime errors during callback execution will 429executing the callback. Runtime errors during callback execution will
308result in the port being C<kil>ed. 430result in the port being C<kil>ed.
309 431
310The default callback received all messages not matched by a more specific 432The default callback receives all messages not matched by a more specific
311C<tag> match. 433C<tag> match.
312 434
313=item rcv $local_port, tag => $callback->(@msg_without_tag), ... 435=item rcv $local_port, tag => $callback->(@msg_without_tag), ...
314 436
315Register (or replace) callbacks to be called on messages starting with the 437Register (or replace) callbacks to be called on messages starting with the
336 msg1 => sub { ... }, 458 msg1 => sub { ... },
337 ... 459 ...
338 ; 460 ;
339 461
340Example: temporarily register a rcv callback for a tag matching some port 462Example: temporarily register a rcv callback for a tag matching some port
341(e.g. for a rpc reply) and unregister it after a message was received. 463(e.g. for an rpc reply) and unregister it after a message was received.
342 464
343 rcv $port, $otherport => sub { 465 rcv $port, $otherport => sub {
344 my @reply = @_; 466 my @reply = @_;
345 467
346 rcv $SELF, $otherport; 468 rcv $SELF, $otherport;
348 470
349=cut 471=cut
350 472
351sub rcv($@) { 473sub rcv($@) {
352 my $port = shift; 474 my $port = shift;
353 my ($noderef, $portid) = split /#/, $port, 2; 475 my ($nodeid, $portid) = split /#/, $port, 2;
354 476
355 $NODE{$noderef} == $NODE{""} 477 $NODE{$nodeid} == $NODE{""}
356 or Carp::croak "$port: rcv can only be called on local ports, caught"; 478 or Carp::croak "$port: rcv can only be called on local ports, caught";
357 479
358 while (@_) { 480 while (@_) {
359 if (ref $_[0]) { 481 if (ref $_[0]) {
360 if (my $self = $PORT_DATA{$portid}) { 482 if (my $self = $PORT_DATA{$portid}) {
361 "AnyEvent::MP::Port" eq ref $self 483 "AnyEvent::MP::Port" eq ref $self
362 or Carp::croak "$port: rcv can only be called on message matching ports, caught"; 484 or Carp::croak "$port: rcv can only be called on message matching ports, caught";
363 485
364 $self->[2] = shift; 486 $self->[0] = shift;
365 } else { 487 } else {
366 my $cb = shift; 488 my $cb = shift;
367 $PORT{$portid} = sub { 489 $PORT{$portid} = sub {
368 local $SELF = $port; 490 local $SELF = $port;
369 eval { &$cb }; _self_die if $@; 491 eval { &$cb }; _self_die if $@;
370 }; 492 };
371 } 493 }
372 } elsif (defined $_[0]) { 494 } elsif (defined $_[0]) {
373 my $self = $PORT_DATA{$portid} ||= do { 495 my $self = $PORT_DATA{$portid} ||= do {
374 my $self = bless [$PORT{$port} || sub { }, { }, $port], "AnyEvent::MP::Port"; 496 my $self = bless [$PORT{$portid} || sub { }, { }, $port], "AnyEvent::MP::Port";
375 497
376 $PORT{$portid} = sub { 498 $PORT{$portid} = sub {
377 local $SELF = $port; 499 local $SELF = $port;
378 500
379 if (my $cb = $self->[1]{$_[0]}) { 501 if (my $cb = $self->[1]{$_[0]}) {
401 } 523 }
402 524
403 $port 525 $port
404} 526}
405 527
528=item peval $port, $coderef[, @args]
529
530Evaluates the given C<$codref> within the contetx of C<$port>, that is,
531when the code throews an exception the C<$port> will be killed.
532
533Any remaining args will be passed to the callback. Any return values will
534be returned to the caller.
535
536This is useful when you temporarily want to execute code in the context of
537a port.
538
539Example: create a port and run some initialisation code in it's context.
540
541 my $port = port { ... };
542
543 peval $port, sub {
544 init
545 or die "unable to init";
546 };
547
548=cut
549
550sub peval($$) {
551 local $SELF = shift;
552 my $cb = shift;
553
554 if (wantarray) {
555 my @res = eval { &$cb };
556 _self_die if $@;
557 @res
558 } else {
559 my $res = eval { &$cb };
560 _self_die if $@;
561 $res
562 }
563}
564
406=item $closure = psub { BLOCK } 565=item $closure = psub { BLOCK }
407 566
408Remembers C<$SELF> and creates a closure out of the BLOCK. When the 567Remembers C<$SELF> and creates a closure out of the BLOCK. When the
409closure is executed, sets up the environment in the same way as in C<rcv> 568closure is executed, sets up the environment in the same way as in C<rcv>
410callbacks, i.e. runtime errors will cause the port to get C<kil>ed. 569callbacks, i.e. runtime errors will cause the port to get C<kil>ed.
570
571The effect is basically as if it returned C<< sub { peval $SELF, sub {
572BLOCK }, @_ } >>.
411 573
412This is useful when you register callbacks from C<rcv> callbacks: 574This is useful when you register callbacks from C<rcv> callbacks:
413 575
414 rcv delayed_reply => sub { 576 rcv delayed_reply => sub {
415 my ($delay, @reply) = @_; 577 my ($delay, @reply) = @_;
451 613
452Monitor the given port and do something when the port is killed or 614Monitor the given port and do something when the port is killed or
453messages to it were lost, and optionally return a guard that can be used 615messages to it were lost, and optionally return a guard that can be used
454to stop monitoring again. 616to stop monitoring again.
455 617
618In the first form (callback), the callback is simply called with any
619number of C<@reason> elements (no @reason means that the port was deleted
620"normally"). Note also that I<< the callback B<must> never die >>, so use
621C<eval> if unsure.
622
623In the second form (another port given), the other port (C<$rcvport>)
624will be C<kil>'ed with C<@reason>, if a @reason was specified, i.e. on
625"normal" kils nothing happens, while under all other conditions, the other
626port is killed with the same reason.
627
628The third form (kill self) is the same as the second form, except that
629C<$rvport> defaults to C<$SELF>.
630
631In the last form (message), a message of the form C<@msg, @reason> will be
632C<snd>.
633
634Monitoring-actions are one-shot: once messages are lost (and a monitoring
635alert was raised), they are removed and will not trigger again.
636
637As a rule of thumb, monitoring requests should always monitor a port from
638a local port (or callback). The reason is that kill messages might get
639lost, just like any other message. Another less obvious reason is that
640even monitoring requests can get lost (for example, when the connection
641to the other node goes down permanently). When monitoring a port locally
642these problems do not exist.
643
456C<mon> effectively guarantees that, in the absence of hardware failures, 644C<mon> effectively guarantees that, in the absence of hardware failures,
457after starting the monitor, either all messages sent to the port will 645after starting the monitor, either all messages sent to the port will
458arrive, or the monitoring action will be invoked after possible message 646arrive, or the monitoring action will be invoked after possible message
459loss has been detected. No messages will be lost "in between" (after 647loss has been detected. No messages will be lost "in between" (after
460the first lost message no further messages will be received by the 648the first lost message no further messages will be received by the
461port). After the monitoring action was invoked, further messages might get 649port). After the monitoring action was invoked, further messages might get
462delivered again. 650delivered again.
463 651
464Note that monitoring-actions are one-shot: once messages are lost (and a 652Inter-host-connection timeouts and monitoring depend on the transport
465monitoring alert was raised), they are removed and will not trigger again. 653used. The only transport currently implemented is TCP, and AnyEvent::MP
654relies on TCP to detect node-downs (this can take 10-15 minutes on a
655non-idle connection, and usually around two hours for idle connections).
466 656
467In the first form (callback), the callback is simply called with any 657This means that monitoring is good for program errors and cleaning up
468number of C<@reason> elements (no @reason means that the port was deleted 658stuff eventually, but they are no replacement for a timeout when you need
469"normally"). Note also that I<< the callback B<must> never die >>, so use 659to ensure some maximum latency.
470C<eval> if unsure.
471
472In the second form (another port given), the other port (C<$rcvport>)
473will be C<kil>'ed with C<@reason>, iff a @reason was specified, i.e. on
474"normal" kils nothing happens, while under all other conditions, the other
475port is killed with the same reason.
476
477The third form (kill self) is the same as the second form, except that
478C<$rvport> defaults to C<$SELF>.
479
480In the last form (message), a message of the form C<@msg, @reason> will be
481C<snd>.
482
483As a rule of thumb, monitoring requests should always monitor a port from
484a local port (or callback). The reason is that kill messages might get
485lost, just like any other message. Another less obvious reason is that
486even monitoring requests can get lost (for exmaple, when the connection
487to the other node goes down permanently). When monitoring a port locally
488these problems do not exist.
489 660
490Example: call a given callback when C<$port> is killed. 661Example: call a given callback when C<$port> is killed.
491 662
492 mon $port, sub { warn "port died because of <@_>\n" }; 663 mon $port, sub { warn "port died because of <@_>\n" };
493 664
500 mon $port, $self => "restart"; 671 mon $port, $self => "restart";
501 672
502=cut 673=cut
503 674
504sub mon { 675sub mon {
505 my ($noderef, $port) = split /#/, shift, 2; 676 my ($nodeid, $port) = split /#/, shift, 2;
506 677
507 my $node = $NODE{$noderef} || add_node $noderef; 678 my $node = $NODE{$nodeid} || add_node $nodeid;
508 679
509 my $cb = @_ ? shift : $SELF || Carp::croak 'mon: called with one argument only, but $SELF not set,'; 680 my $cb = @_ ? shift : $SELF || Carp::croak 'mon: called with one argument only, but $SELF not set,';
510 681
511 unless (ref $cb) { 682 unless (ref $cb) {
512 if (@_) { 683 if (@_) {
521 } 692 }
522 693
523 $node->monitor ($port, $cb); 694 $node->monitor ($port, $cb);
524 695
525 defined wantarray 696 defined wantarray
526 and AnyEvent::Util::guard { $node->unmonitor ($port, $cb) } 697 and ($cb += 0, Guard::guard { $node->unmonitor ($port, $cb) })
527} 698}
528 699
529=item $guard = mon_guard $port, $ref, $ref... 700=item $guard = mon_guard $port, $ref, $ref...
530 701
531Monitors the given C<$port> and keeps the passed references. When the port 702Monitors the given C<$port> and keeps the passed references. When the port
554 725
555=item kil $port[, @reason] 726=item kil $port[, @reason]
556 727
557Kill the specified port with the given C<@reason>. 728Kill the specified port with the given C<@reason>.
558 729
559If no C<@reason> is specified, then the port is killed "normally" (ports 730If no C<@reason> is specified, then the port is killed "normally" -
560monitoring other ports will not necessarily die because a port dies 731monitor callback will be invoked, but the kil will not cause linked ports
561"normally"). 732(C<mon $mport, $lport> form) to get killed.
562 733
563Otherwise, linked ports get killed with the same reason (second form of 734If a C<@reason> is specified, then linked ports (C<mon $mport, $lport>
564C<mon>, see above). 735form) get killed with the same reason.
565 736
566Runtime errors while evaluating C<rcv> callbacks or inside C<psub> blocks 737Runtime errors while evaluating C<rcv> callbacks or inside C<psub> blocks
567will be reported as reason C<< die => $@ >>. 738will be reported as reason C<< die => $@ >>.
568 739
569Transport/communication errors are reported as C<< transport_error => 740Transport/communication errors are reported as C<< transport_error =>
570$message >>. 741$message >>.
571 742
572=cut 743Common idioms:
744
745 # silently remove yourself, do not kill linked ports
746 kil $SELF;
747
748 # report a failure in some detail
749 kil $SELF, failure_mode_1 => "it failed with too high temperature";
750
751 # do not waste much time with killing, just die when something goes wrong
752 open my $fh, "<file"
753 or die "file: $!";
573 754
574=item $port = spawn $node, $initfunc[, @initdata] 755=item $port = spawn $node, $initfunc[, @initdata]
575 756
576Creates a port on the node C<$node> (which can also be a port ID, in which 757Creates a port on the node C<$node> (which can also be a port ID, in which
577case it's the node where that port resides). 758case it's the node where that port resides).
588the package, then the package above the package and so on (e.g. 769the package, then the package above the package and so on (e.g.
589C<MyApp::Chat::Server>, C<MyApp::Chat>, C<MyApp>) until the function 770C<MyApp::Chat::Server>, C<MyApp::Chat>, C<MyApp>) until the function
590exists or it runs out of package names. 771exists or it runs out of package names.
591 772
592The init function is then called with the newly-created port as context 773The init function is then called with the newly-created port as context
593object (C<$SELF>) and the C<@initdata> values as arguments. 774object (C<$SELF>) and the C<@initdata> values as arguments. It I<must>
775call one of the C<rcv> functions to set callbacks on C<$SELF>, otherwise
776the port might not get created.
594 777
595A common idiom is to pass a local port, immediately monitor the spawned 778A common idiom is to pass a local port, immediately monitor the spawned
596port, and in the remote init function, immediately monitor the passed 779port, and in the remote init function, immediately monitor the passed
597local port. This two-way monitoring ensures that both ports get cleaned up 780local port. This two-way monitoring ensures that both ports get cleaned up
598when there is a problem. 781when there is a problem.
599 782
783C<spawn> guarantees that the C<$initfunc> has no visible effects on the
784caller before C<spawn> returns (by delaying invocation when spawn is
785called for the local node).
786
600Example: spawn a chat server port on C<$othernode>. 787Example: spawn a chat server port on C<$othernode>.
601 788
602 # this node, executed from within a port context: 789 # this node, executed from within a port context:
603 my $server = spawn $othernode, "MyApp::Chat::Server::connect", $SELF; 790 my $server = spawn $othernode, "MyApp::Chat::Server::connect", $SELF;
604 mon $server; 791 mon $server;
618 805
619sub _spawn { 806sub _spawn {
620 my $port = shift; 807 my $port = shift;
621 my $init = shift; 808 my $init = shift;
622 809
810 # rcv will create the actual port
623 local $SELF = "$NODE#$port"; 811 local $SELF = "$NODE#$port";
624 eval { 812 eval {
625 &{ load_func $init } 813 &{ load_func $init }
626 }; 814 };
627 _self_die if $@; 815 _self_die if $@;
628} 816}
629 817
630sub spawn(@) { 818sub spawn(@) {
631 my ($noderef, undef) = split /#/, shift, 2; 819 my ($nodeid, undef) = split /#/, shift, 2;
632 820
633 my $id = "$RUNIQ." . $ID++; 821 my $id = $RUNIQ . ++$ID;
634 822
635 $_[0] =~ /::/ 823 $_[0] =~ /::/
636 or Carp::croak "spawn init function must be a fully-qualified name, caught"; 824 or Carp::croak "spawn init function must be a fully-qualified name, caught";
637 825
638 snd_to_func $noderef, "AnyEvent::MP::_spawn" => $id, @_; 826 snd_to_func $nodeid, "AnyEvent::MP::_spawn" => $id, @_;
639 827
640 "$noderef#$id" 828 "$nodeid#$id"
641} 829}
830
642 831
643=item after $timeout, @msg 832=item after $timeout, @msg
644 833
645=item after $timeout, $callback 834=item after $timeout, $callback
646 835
662 ? $action[0]() 851 ? $action[0]()
663 : snd @action; 852 : snd @action;
664 }; 853 };
665} 854}
666 855
856#=item $cb2 = timeout $seconds, $cb[, @args]
857
858=item cal $port, @msg, $callback[, $timeout]
859
860A simple form of RPC - sends a message to the given C<$port> with the
861given contents (C<@msg>), but adds a reply port to the message.
862
863The reply port is created temporarily just for the purpose of receiving
864the reply, and will be C<kil>ed when no longer needed.
865
866A reply message sent to the port is passed to the C<$callback> as-is.
867
868If an optional time-out (in seconds) is given and it is not C<undef>,
869then the callback will be called without any arguments after the time-out
870elapsed and the port is C<kil>ed.
871
872If no time-out is given (or it is C<undef>), then the local port will
873monitor the remote port instead, so it eventually gets cleaned-up.
874
875Currently this function returns the temporary port, but this "feature"
876might go in future versions unless you can make a convincing case that
877this is indeed useful for something.
878
879=cut
880
881sub cal(@) {
882 my $timeout = ref $_[-1] ? undef : pop;
883 my $cb = pop;
884
885 my $port = port {
886 undef $timeout;
887 kil $SELF;
888 &$cb;
889 };
890
891 if (defined $timeout) {
892 $timeout = AE::timer $timeout, 0, sub {
893 undef $timeout;
894 kil $port;
895 $cb->();
896 };
897 } else {
898 mon $_[0], sub {
899 kil $port;
900 $cb->();
901 };
902 }
903
904 push @_, $port;
905 &snd;
906
907 $port
908}
909
910=back
911
912=head1 DISTRIBUTED DATABASE
913
914AnyEvent::MP comes with a simple distributed database. The database will
915be mirrored asynchronously on all global nodes. Other nodes bind to one
916of the global nodes for their needs. Every node has a "local database"
917which contains all the values that are set locally. All local databases
918are merged together to form the global database, which can be queried.
919
920The database structure is that of a two-level hash - the database hash
921contains hashes which contain values, similarly to a perl hash of hashes,
922i.e.:
923
924 $DATABASE{$family}{$subkey} = $value
925
926The top level hash key is called "family", and the second-level hash key
927is called "subkey" or simply "key".
928
929The family must be alphanumeric, i.e. start with a letter and consist
930of letters, digits, underscores and colons (C<[A-Za-z][A-Za-z0-9_:]*>,
931pretty much like Perl module names.
932
933As the family namespace is global, it is recommended to prefix family names
934with the name of the application or module using it.
935
936The subkeys must be non-empty strings, with no further restrictions.
937
938The values should preferably be strings, but other perl scalars should
939work as well (such as C<undef>, arrays and hashes).
940
941Every database entry is owned by one node - adding the same family/subkey
942combination on multiple nodes will not cause discomfort for AnyEvent::MP,
943but the result might be nondeterministic, i.e. the key might have
944different values on different nodes.
945
946Different subkeys in the same family can be owned by different nodes
947without problems, and in fact, this is the common method to create worker
948pools. For example, a worker port for image scaling might do this:
949
950 db_set my_image_scalers => $port;
951
952And clients looking for an image scaler will want to get the
953C<my_image_scalers> keys from time to time:
954
955 db_keys my_image_scalers => sub {
956 @ports = @{ $_[0] };
957 };
958
959Or better yet, they want to monitor the database family, so they always
960have a reasonable up-to-date copy:
961
962 db_mon my_image_scalers => sub {
963 @ports = keys %{ $_[0] };
964 };
965
966In general, you can set or delete single subkeys, but query and monitor
967whole families only.
968
969If you feel the need to monitor or query a single subkey, try giving it
970it's own family.
971
972=over
973
974=item $guard = db_set $family => $subkey [=> $value]
975
976Sets (or replaces) a key to the database - if C<$value> is omitted,
977C<undef> is used instead.
978
979When called in non-void context, C<db_set> returns a guard that
980automatically calls C<db_del> when it is destroyed.
981
982=item db_del $family => $subkey...
983
984Deletes one or more subkeys from the database family.
985
986=item $guard = db_reg $family => $port => $value
987
988=item $guard = db_reg $family => $port
989
990=item $guard = db_reg $family
991
992Registers a port in the given family and optionally returns a guard to
993remove it.
994
995This function basically does the same as:
996
997 db_set $family => $port => $value
998
999Except that the port is monitored and automatically removed from the
1000database family when it is kil'ed.
1001
1002If C<$value> is missing, C<undef> is used. If C<$port> is missing, then
1003C<$SELF> is used.
1004
1005This function is most useful to register a port in some port group (which
1006is just another name for a database family), and have it removed when the
1007port is gone. This works best when the port is a local port.
1008
1009=cut
1010
1011sub db_reg($$;$) {
1012 my $family = shift;
1013 my $port = @_ ? shift : $SELF;
1014
1015 my $clr = sub { db_del $family => $port };
1016 mon $port, $clr;
1017
1018 db_set $family => $port => $_[0];
1019
1020 defined wantarray
1021 and &Guard::guard ($clr)
1022}
1023
1024=item db_family $family => $cb->(\%familyhash)
1025
1026Queries the named database C<$family> and call the callback with the
1027family represented as a hash. You can keep and freely modify the hash.
1028
1029=item db_keys $family => $cb->(\@keys)
1030
1031Same as C<db_family>, except it only queries the family I<subkeys> and passes
1032them as array reference to the callback.
1033
1034=item db_values $family => $cb->(\@values)
1035
1036Same as C<db_family>, except it only queries the family I<values> and passes them
1037as array reference to the callback.
1038
1039=item $guard = db_mon $family => $cb->($familyhash, \@added, \@changed, \@deleted)
1040
1041Creates a monitor on the given database family. Each time a key is set
1042or or is deleted the callback is called with a hash containing the
1043database family and three lists of added, changed and deleted subkeys,
1044respectively. If no keys have changed then the array reference might be
1045C<undef> or even missing.
1046
1047If not called in void context, a guard object is returned that, when
1048destroyed, stops the monitor.
1049
1050The family hash reference and the key arrays belong to AnyEvent::MP and
1051B<must not be modified or stored> by the callback. When in doubt, make a
1052copy.
1053
1054As soon as possible after the monitoring starts, the callback will be
1055called with the intiial contents of the family, even if it is empty,
1056i.e. there will always be a timely call to the callback with the current
1057contents.
1058
1059It is possible that the callback is called with a change event even though
1060the subkey is already present and the value has not changed.
1061
1062The monitoring stops when the guard object is destroyed.
1063
1064Example: on every change to the family "mygroup", print out all keys.
1065
1066 my $guard = db_mon mygroup => sub {
1067 my ($family, $a, $c, $d) = @_;
1068 print "mygroup members: ", (join " ", keys %$family), "\n";
1069 };
1070
1071Exmaple: wait until the family "My::Module::workers" is non-empty.
1072
1073 my $guard; $guard = db_mon My::Module::workers => sub {
1074 my ($family, $a, $c, $d) = @_;
1075 return unless %$family;
1076 undef $guard;
1077 print "My::Module::workers now nonempty\n";
1078 };
1079
1080Example: print all changes to the family "AnyRvent::Fantasy::Module".
1081
1082 my $guard = db_mon AnyRvent::Fantasy::Module => sub {
1083 my ($family, $a, $c, $d) = @_;
1084
1085 print "+$_=$family->{$_}\n" for @$a;
1086 print "*$_=$family->{$_}\n" for @$c;
1087 print "-$_=$family->{$_}\n" for @$d;
1088 };
1089
1090=cut
1091
667=back 1092=back
668 1093
669=head1 AnyEvent::MP vs. Distributed Erlang 1094=head1 AnyEvent::MP vs. Distributed Erlang
670 1095
671AnyEvent::MP got lots of its ideas from distributed Erlang (Erlang node 1096AnyEvent::MP got lots of its ideas from distributed Erlang (Erlang node
672== aemp node, Erlang process == aemp port), so many of the documents and 1097== aemp node, Erlang process == aemp port), so many of the documents and
673programming techniques employed by Erlang apply to AnyEvent::MP. Here is a 1098programming techniques employed by Erlang apply to AnyEvent::MP. Here is a
674sample: 1099sample:
675 1100
676 http://www.Erlang.se/doc/programming_rules.shtml 1101 http://www.erlang.se/doc/programming_rules.shtml
677 http://Erlang.org/doc/getting_started/part_frame.html # chapters 3 and 4 1102 http://erlang.org/doc/getting_started/part_frame.html # chapters 3 and 4
678 http://Erlang.org/download/Erlang-book-part1.pdf # chapters 5 and 6 1103 http://erlang.org/download/erlang-book-part1.pdf # chapters 5 and 6
679 http://Erlang.org/download/armstrong_thesis_2003.pdf # chapters 4 and 5 1104 http://erlang.org/download/armstrong_thesis_2003.pdf # chapters 4 and 5
680 1105
681Despite the similarities, there are also some important differences: 1106Despite the similarities, there are also some important differences:
682 1107
683=over 4 1108=over 4
684 1109
685=item * Node IDs are arbitrary strings in AEMP. 1110=item * Node IDs are arbitrary strings in AEMP.
686 1111
687Erlang relies on special naming and DNS to work everywhere in the same 1112Erlang relies on special naming and DNS to work everywhere in the same
688way. AEMP relies on each node somehow knowing its own address(es) (e.g. by 1113way. AEMP relies on each node somehow knowing its own address(es) (e.g. by
689configuraiton or DNS), but will otherwise discover other odes itself. 1114configuration or DNS), and possibly the addresses of some seed nodes, but
1115will otherwise discover other nodes (and their IDs) itself.
690 1116
691=item * Erlang has a "remote ports are like local ports" philosophy, AEMP 1117=item * Erlang has a "remote ports are like local ports" philosophy, AEMP
692uses "local ports are like remote ports". 1118uses "local ports are like remote ports".
693 1119
694The failure modes for local ports are quite different (runtime errors 1120The failure modes for local ports are quite different (runtime errors
703ports being the special case/exception, where transport errors cannot 1129ports being the special case/exception, where transport errors cannot
704occur. 1130occur.
705 1131
706=item * Erlang uses processes and a mailbox, AEMP does not queue. 1132=item * Erlang uses processes and a mailbox, AEMP does not queue.
707 1133
708Erlang uses processes that selectively receive messages, and therefore 1134Erlang uses processes that selectively receive messages out of order, and
709needs a queue. AEMP is event based, queuing messages would serve no 1135therefore needs a queue. AEMP is event based, queuing messages would serve
710useful purpose. For the same reason the pattern-matching abilities of 1136no useful purpose. For the same reason the pattern-matching abilities
711AnyEvent::MP are more limited, as there is little need to be able to 1137of AnyEvent::MP are more limited, as there is little need to be able to
712filter messages without dequeing them. 1138filter messages without dequeuing them.
713 1139
714(But see L<Coro::MP> for a more Erlang-like process model on top of AEMP). 1140This is not a philosophical difference, but simply stems from AnyEvent::MP
1141being event-based, while Erlang is process-based.
1142
1143You cna have a look at L<Coro::MP> for a more Erlang-like process model on
1144top of AEMP and Coro threads.
715 1145
716=item * Erlang sends are synchronous, AEMP sends are asynchronous. 1146=item * Erlang sends are synchronous, AEMP sends are asynchronous.
717 1147
718Sending messages in Erlang is synchronous and blocks the process (and 1148Sending messages in Erlang is synchronous and blocks the process until
1149a conenction has been established and the message sent (and so does not
719so does not need a queue that can overflow). AEMP sends are immediate, 1150need a queue that can overflow). AEMP sends return immediately, connection
720connection establishment is handled in the background. 1151establishment is handled in the background.
721 1152
722=item * Erlang suffers from silent message loss, AEMP does not. 1153=item * Erlang suffers from silent message loss, AEMP does not.
723 1154
724Erlang makes few guarantees on messages delivery - messages can get lost 1155Erlang implements few guarantees on messages delivery - messages can get
725without any of the processes realising it (i.e. you send messages a, b, 1156lost without any of the processes realising it (i.e. you send messages a,
726and c, and the other side only receives messages a and c). 1157b, and c, and the other side only receives messages a and c).
727 1158
728AEMP guarantees correct ordering, and the guarantee that after one message 1159AEMP guarantees (modulo hardware errors) correct ordering, and the
729is lost, all following ones sent to the same port are lost as well, until 1160guarantee that after one message is lost, all following ones sent to the
730monitoring raises an error, so there are no silent "holes" in the message 1161same port are lost as well, until monitoring raises an error, so there are
731sequence. 1162no silent "holes" in the message sequence.
1163
1164If you want your software to be very reliable, you have to cope with
1165corrupted and even out-of-order messages in both Erlang and AEMP. AEMP
1166simply tries to work better in common error cases, such as when a network
1167link goes down.
732 1168
733=item * Erlang can send messages to the wrong port, AEMP does not. 1169=item * Erlang can send messages to the wrong port, AEMP does not.
734 1170
735In Erlang it is quite likely that a node that restarts reuses a process ID 1171In Erlang it is quite likely that a node that restarts reuses an Erlang
736known to other nodes for a completely different process, causing messages 1172process ID known to other nodes for a completely different process,
737destined for that process to end up in an unrelated process. 1173causing messages destined for that process to end up in an unrelated
1174process.
738 1175
739AEMP never reuses port IDs, so old messages or old port IDs floating 1176AEMP does not reuse port IDs, so old messages or old port IDs floating
740around in the network will not be sent to an unrelated port. 1177around in the network will not be sent to an unrelated port.
741 1178
742=item * Erlang uses unprotected connections, AEMP uses secure 1179=item * Erlang uses unprotected connections, AEMP uses secure
743authentication and can use TLS. 1180authentication and can use TLS.
744 1181
747 1184
748=item * The AEMP protocol is optimised for both text-based and binary 1185=item * The AEMP protocol is optimised for both text-based and binary
749communications. 1186communications.
750 1187
751The AEMP protocol, unlike the Erlang protocol, supports both programming 1188The AEMP protocol, unlike the Erlang protocol, supports both programming
752language independent text-only protocols (good for debugging) and binary, 1189language independent text-only protocols (good for debugging), and binary,
753language-specific serialisers (e.g. Storable). By default, unless TLS is 1190language-specific serialisers (e.g. Storable). By default, unless TLS is
754used, the protocol is actually completely text-based. 1191used, the protocol is actually completely text-based.
755 1192
756It has also been carefully designed to be implementable in other languages 1193It has also been carefully designed to be implementable in other languages
757with a minimum of work while gracefully degrading functionality to make the 1194with a minimum of work while gracefully degrading functionality to make the
758protocol simple. 1195protocol simple.
759 1196
760=item * AEMP has more flexible monitoring options than Erlang. 1197=item * AEMP has more flexible monitoring options than Erlang.
761 1198
762In Erlang, you can chose to receive I<all> exit signals as messages 1199In Erlang, you can chose to receive I<all> exit signals as messages or
763or I<none>, there is no in-between, so monitoring single processes is 1200I<none>, there is no in-between, so monitoring single Erlang processes is
764difficult to implement. Monitoring in AEMP is more flexible than in 1201difficult to implement.
765Erlang, as one can choose between automatic kill, exit message or callback 1202
766on a per-process basis. 1203Monitoring in AEMP is more flexible than in Erlang, as one can choose
1204between automatic kill, exit message or callback on a per-port basis.
767 1205
768=item * Erlang tries to hide remote/local connections, AEMP does not. 1206=item * Erlang tries to hide remote/local connections, AEMP does not.
769 1207
770Monitoring in Erlang is not an indicator of process death/crashes, in the 1208Monitoring in Erlang is not an indicator of process death/crashes, in the
771same way as linking is (except linking is unreliable in Erlang). 1209same way as linking is (except linking is unreliable in Erlang).
793overhead, as well as having to keep a proxy object everywhere. 1231overhead, as well as having to keep a proxy object everywhere.
794 1232
795Strings can easily be printed, easily serialised etc. and need no special 1233Strings can easily be printed, easily serialised etc. and need no special
796procedures to be "valid". 1234procedures to be "valid".
797 1235
798And as a result, a miniport consists of a single closure stored in a 1236And as a result, a port with just a default receiver consists of a single
799global hash - it can't become much cheaper. 1237code reference stored in a global hash - it can't become much cheaper.
800 1238
801=item Why favour JSON, why not a real serialising format such as Storable? 1239=item Why favour JSON, why not a real serialising format such as Storable?
802 1240
803In fact, any AnyEvent::MP node will happily accept Storable as framing 1241In fact, any AnyEvent::MP node will happily accept Storable as framing
804format, but currently there is no way to make a node use Storable by 1242format, but currently there is no way to make a node use Storable by
814Keeping your messages simple, concentrating on data structures rather than 1252Keeping your messages simple, concentrating on data structures rather than
815objects, will keep your messages clean, tidy and efficient. 1253objects, will keep your messages clean, tidy and efficient.
816 1254
817=back 1255=back
818 1256
1257=head1 PORTING FROM AnyEvent::MP VERSION 1.X
1258
1259AEMP version 2 has three major incompatible changes compared to version 1:
1260
1261=over 4
1262
1263=item AnyEvent::MP::Global no longer has group management functions.
1264
1265AnyEvent::MP now comes with a distributed database that is more
1266powerful. It's database families map closely to ports, but the API has
1267minor differences:
1268
1269 grp_reg $group, $port # old
1270 db_reg $group, $port # new
1271
1272 $list = grp_get $group # old
1273 db_keys $group, sub { my $list = shift } # new
1274
1275 grp_mon $group, $cb->(\@ports, $add, $del) # old
1276 db_mon $group, $cb->(\%ports, $add, $change, $del) # new
1277
1278C<grp_reg> is a no-brainer (just replace by C<db_reg>), but C<grp_get>
1279is no longer instant, because the local node might not have a copy of
1280the group. This can be partially remedied by using C<db_mon> to keep an
1281updated copy of the group:
1282
1283 my $local_group_copy;
1284 db_mon $group => sub { $local_group_copy = shift };
1285
1286 # no keys %$local_group_copy always returns the most up-to-date
1287 # list of ports in the group.
1288
1289C<grp_mon> can almost be replaced by C<db_mon>:
1290
1291 db_mon $group => sub {
1292 my ($ports, $add, $chg, $lde) = @_;
1293 $ports = [keys %$ports];
1294
1295 # now $ports, $add and $del are the same as
1296 # were originally passed by grp_mon.
1297 ...
1298 };
1299
1300=item Nodes not longer connect to all other nodes.
1301
1302In AEMP 1.x, every node automatically loads the L<AnyEvent::MP::Global>
1303module, which in turn would create connections to all other nodes in the
1304network (helped by the seed nodes).
1305
1306In version 2.x, global nodes still connect to all other global nodes, but
1307other nodes don't - now every node either is a global node itself, or
1308attaches itself to another global node.
1309
1310If a node isn't a global node itself, then it attaches itself to one
1311of its seed nodes. If that seed node isn't a global node yet, it will
1312automatically be upgraded to a global node.
1313
1314So in many cases, nothing needs to be changed - one just has to make sure
1315that all seed nodes are meshed together with the other seed nodes (as with
1316AEMP 1.x), and other nodes specify them as seed nodes.
1317
1318Not opening a connection to every other node is usually an advantage,
1319except when you need the lower latency of an already established
1320connection. To ensure a node establishes a connection to another node,
1321you can monitor the node port (C<mon $node, ...>), which will attempt to
1322create the connection (and notify you when the connection fails).
1323
1324=item Listener-less nodes (nodes without binds) are gone.
1325
1326And are not coming back, at least not in their old form. If no C<binds>
1327are specified for a node, AnyEvent::MP now assumes a default of C<*:*>.
1328
1329There are vague plans to implement some form of routing domains, which
1330might or might not bring back listener-less nodes, but don't count on it.
1331
1332The fact that most connections are now optional somewhat mitigates this,
1333as a node can be effectively unreachable from the outside without any
1334problems, as long as it isn't a global node and only reaches out to other
1335nodes (as opposed to being contacted from other nodes).
1336
1337=item $AnyEvent::MP::Kernel::WARN has gone.
1338
1339AnyEvent has acquired a logging framework (L<AnyEvent::Log>), and AEMP now
1340uses this, and so should your programs.
1341
1342Every module now documents what kinds of messages it generates, with
1343AnyEvent::MP acting as a catch all.
1344
1345On the positive side, this means that instead of setting
1346C<PERL_ANYEVENT_MP_WARNLEVEL>, you can get away by setting C<AE_VERBOSE>,
1347much less to type.
1348
1349=back
1350
819=head1 SEE ALSO 1351=head1 SEE ALSO
820 1352
821L<AnyEvent::MP::Intro> - a gentle introduction. 1353L<AnyEvent::MP::Intro> - a gentle introduction.
822 1354
823L<AnyEvent::MP::Kernel> - more, lower-level, stuff. 1355L<AnyEvent::MP::Kernel> - more, lower-level, stuff.
824 1356
825L<AnyEvent::MP::Global> - network maintainance and port groups, to find 1357L<AnyEvent::MP::Global> - network maintenance and port groups, to find
826your applications. 1358your applications.
1359
1360L<AnyEvent::MP::DataConn> - establish data connections between nodes.
1361
1362L<AnyEvent::MP::LogCatcher> - simple service to display log messages from
1363all nodes.
827 1364
828L<AnyEvent>. 1365L<AnyEvent>.
829 1366
830=head1 AUTHOR 1367=head1 AUTHOR
831 1368

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines