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.29 by root, Tue Aug 4 23:16:57 2009 UTC vs.
Revision 1.134 by root, Mon Mar 12 14:47:23 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
12 $SELF # receiving/own port id in rcv callbacks
13
14 # initialise the node so it can send/receive messages
15 configure;
16
17 # ports are message destinations
18
19 # sending messages
13 snd $port, type => data...; 20 snd $port, type => data...;
21 snd $port, @msg;
22 snd @msg_with_first_element_being_a_port;
14 23
15 $SELF # receiving/own port id in rcv callbacks 24 # creating/using ports, the simple way
25 my $simple_port = port { my @msg = @_ };
16 26
17 rcv $port, smartmatch => $cb->($port, @msg); 27 # creating/using ports, tagged message matching
18 28 my $port = port;
19 # examples:
20 rcv $port2, ping => sub { snd $_[0], "pong"; 0 }; 29 rcv $port, ping => sub { snd $_[0], "pong" };
21 rcv $port1, pong => sub { warn "pong received\n" }; 30 rcv $port, pong => sub { warn "pong received\n" };
22 snd $port2, ping => $port1;
23 31
24 # more, smarter, matches (_any_ is exported by this module) 32 # create a port on another node
25 rcv $port, [child_died => $pid] => sub { ... 33 my $port = spawn $node, $initfunc, @initdata;
26 rcv $port, [_any_, _any_, 3] => sub { .. $_[2] is 3 34
35 # destroy a port again
36 kil $port; # "normal" kill
37 kil $port, my_error => "everything is broken"; # error kill
38
39 # monitoring
40 mon $port, $cb->(@msg) # callback is invoked on death
41 mon $port, $localport # kill localport on abnormal 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 };
51
52=head1 CURRENT STATUS
53
54 bin/aemp - stable.
55 AnyEvent::MP - stable API, should work.
56 AnyEvent::MP::Intro - explains most concepts.
57 AnyEvent::MP::Kernel - mostly stable API.
58 AnyEvent::MP::Global - stable API.
27 59
28=head1 DESCRIPTION 60=head1 DESCRIPTION
29 61
30This module (-family) implements a simple message passing framework. 62This module (-family) implements a simple message passing framework.
31 63
32Despite its simplicity, you can securely message other processes running 64Despite its simplicity, you can securely message other processes running
33on the same or other hosts. 65on the same or other hosts, and you can supervise entities remotely.
34 66
35For 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>
36manual page. 68manual page and the examples under F<eg/>.
37
38At the moment, this module family is severly broken and underdocumented,
39so do not use. This was uploaded mainly to reserve the CPAN namespace -
40stay tuned! The basic API should be finished, however.
41 69
42=head1 CONCEPTS 70=head1 CONCEPTS
43 71
44=over 4 72=over 4
45 73
46=item port 74=item port
47 75
48A 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).
49 78
50Some ports allow you to register C<rcv> handlers that can match specific 79Ports allow you to register C<rcv> handlers that can match all or just
51messages. All C<rcv> handlers will receive messages they match, messages 80some messages. Messages send to ports will not be queued, regardless of
52will not be queued. 81anything was listening for them or not.
53 82
83Ports are represented by (printable) strings called "port IDs".
84
54=item port id - C<noderef#portname> 85=item port ID - C<nodeid#portname>
55 86
56A port id is normaly the concatenation of a noderef, a hash-mark (C<#>) as 87A port ID is the concatenation of a node ID, a hash-mark (C<#>)
57separator, and a port name (a printable string of unspecified format). An 88as separator, and a port name (a printable string of unspecified
58exception is the the node port, whose ID is identical to it's node 89format created by AnyEvent::MP).
59reference.
60 90
61=item node 91=item node
62 92
63A node is a single process containing at least one port - the node 93A node is a single process containing at least one port - the node port,
64port. You can send messages to node ports to find existing ports or to 94which enables nodes to manage each other remotely, and to create new
65create new ports, among other things. 95ports.
66 96
67Nodes are either private (single-process only), slaves (connected to a 97Nodes are either public (have one or more listening ports) or private
68master node only) or public nodes (connectable from unrelated nodes). 98(no listening ports). Private nodes cannot talk to other private nodes
99currently, but all nodes can talk to public nodes.
69 100
70=item noderef - C<host:port,host:port...>, C<id@noderef>, C<id> 101Nodes is represented by (printable) strings called "node IDs".
71 102
72A node reference is a string that either simply identifies the node (for 103=item node ID - C<[A-Za-z0-9_\-.:]*>
73private and slave nodes), or contains a recipe on how to reach a given
74node (for public nodes).
75 104
76This recipe is simply a comma-separated list of C<address:port> pairs (for 105A node ID is a string that uniquely identifies the node within a
77TCP/IP, other protocols might look different). 106network. Depending on the configuration used, node IDs can look like a
107hostname, a hostname and a port, or a random string. AnyEvent::MP itself
108doesn't interpret node IDs in any way except to uniquely identify a node.
78 109
79Node references come in two flavours: resolved (containing only numerical 110=item binds - C<ip:port>
80addresses) or unresolved (where hostnames are used instead of addresses).
81 111
82Before using an unresolved node reference in a message you first have to 112Nodes can only talk to each other by creating some kind of connection to
83resolve it. 113each other. To do this, nodes should listen on one or more local transport
114endpoints - binds.
115
116Currently, only standard C<ip:port> specifications can be used, which
117specify TCP ports to listen on. So a bind is basically just a tcp socket
118in listening mode thta accepts conenctions form other nodes.
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
149=item seed IDs - C<host:port>
150
151Seed IDs are transport endpoint(s) (usually a hostname/IP address and a
152TCP port) of nodes that should be used as seed nodes.
153
154=item global nodes
155
156An AEMP network needs a discovery service - nodes need to know how to
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).
84 170
85=back 171=back
86 172
87=head1 VARIABLES/FUNCTIONS 173=head1 VARIABLES/FUNCTIONS
88 174
90 176
91=cut 177=cut
92 178
93package AnyEvent::MP; 179package AnyEvent::MP;
94 180
181use AnyEvent::MP::Config ();
95use AnyEvent::MP::Base; 182use AnyEvent::MP::Kernel;
183use AnyEvent::MP::Kernel qw(%NODE %PORT %PORT_DATA $UNIQ $RUNIQ $ID);
96 184
97use common::sense; 185use common::sense;
98 186
99use Carp (); 187use Carp ();
100 188
101use AE (); 189use AE ();
190use Guard ();
102 191
103use base "Exporter"; 192use base "Exporter";
104 193
105our $VERSION = '0.1'; 194our $VERSION = $AnyEvent::MP::Config::VERSION;
195
106our @EXPORT = qw( 196our @EXPORT = qw(
107 NODE $NODE *SELF node_of _any_ 197 NODE $NODE *SELF node_of after
108 resolve_node 198 configure
109 become_slave become_public 199 snd rcv mon mon_guard kil psub peval spawn cal
110 snd rcv mon kil reg psub
111 port 200 port
201 db_set db_del db_reg
202 db_mon db_family db_keys db_values
112); 203);
113 204
114our $SELF; 205our $SELF;
115 206
116sub _self_die() { 207sub _self_die() {
119 kil $SELF, die => $msg; 210 kil $SELF, die => $msg;
120} 211}
121 212
122=item $thisnode = NODE / $NODE 213=item $thisnode = NODE / $NODE
123 214
124The C<NODE> function returns, and the C<$NODE> variable contains 215The C<NODE> function returns, and the C<$NODE> variable contains, the node
125the noderef of the local node. The value is initialised by a call 216ID of the node running in the current process. This value is initialised by
126to C<become_public> or C<become_slave>, after which all local port 217a call to C<configure>.
127identifiers become invalid.
128 218
129=item $noderef = node_of $portid 219=item $nodeid = node_of $port
130 220
131Extracts and returns the noderef from a portid or a noderef. 221Extracts and returns the node ID from a port ID or a node ID.
132 222
133=item $cv = resolve_node $noderef 223=item configure $profile, key => value...
134 224
135Takes an unresolved node reference that may contain hostnames and 225=item configure key => value...
136abbreviated IDs, resolves all of them and returns a resolved node
137reference.
138 226
139In addition to C<address:port> pairs allowed in resolved noderefs, the 227Before a node can talk to other nodes on the network (i.e. enter
140following forms are supported: 228"distributed mode") it has to configure itself - the minimum a node needs
229to know is its own name, and optionally it should know the addresses of
230some other nodes in the network to discover other nodes.
231
232This function configures a node - it must be called exactly once (or
233never) before calling other AnyEvent::MP functions.
234
235The key/value pairs are basically the same ones as documented for the
236F<aemp> command line utility (sans the set/del prefix), with these additions:
141 237
142=over 4 238=over 4
143 239
144=item the empty string 240=item norc => $boolean (default false)
145 241
146An empty-string component gets resolved as if the default port (4040) was 242If true, then the rc file (e.g. F<~/.perl-anyevent-mp>) will I<not>
147specified. 243be consulted - all configuraiton options must be specified in the
244C<configure> call.
148 245
149=item naked port numbers (e.g. C<1234>) 246=item force => $boolean (default false)
150 247
151These are resolved by prepending the local nodename and a colon, to be 248IF true, then the values specified in the C<configure> will take
152further resolved. 249precedence over any values configured via the rc file. The default is for
250the rc file to override any options specified in the program.
153 251
154=item hostnames (e.g. C<localhost:1234>, C<localhost>) 252=item secure => $pass->($nodeid)
155 253
156These are resolved by using AnyEvent::DNS to resolve them, optionally 254In addition to specifying a boolean, you can specify a code reference that
157looking up SRV records for the C<aemp=4040> port, if no port was 255is called for every remote execution attempt - the execution request is
158specified. 256granted iff the callback returns a true value.
257
258See F<semp setsecure> for more info.
159 259
160=back 260=back
261
262=over 4
263
264=item step 1, gathering configuration from profiles
265
266The function first looks up a profile in the aemp configuration (see the
267L<aemp> commandline utility). The profile name can be specified via the
268named C<profile> parameter or can simply be the first parameter). If it is
269missing, then the nodename (F<uname -n>) will be used as profile name.
270
271The profile data is then gathered as follows:
272
273First, all remaining key => value pairs (all of which are conveniently
274undocumented at the moment) will be interpreted as configuration
275data. Then they will be overwritten by any values specified in the global
276default configuration (see the F<aemp> utility), then the chain of
277profiles chosen by the profile name (and any C<parent> attributes).
278
279That means that the values specified in the profile have highest priority
280and the values specified directly via C<configure> have lowest priority,
281and can only be used to specify defaults.
282
283If the profile specifies a node ID, then this will become the node ID of
284this process. If not, then the profile name will be used as node ID, with
285a unique randoms tring (C</%u>) appended.
286
287The node ID can contain some C<%> sequences that are expanded: C<%n>
288is expanded to the local nodename, C<%u> is replaced by a random
289strign to make the node unique. For example, the F<aemp> commandline
290utility uses C<aemp/%n/%u> as nodename, which might expand to
291C<aemp/cerebro/ZQDGSIkRhEZQDGSIkRhE>.
292
293=item step 2, bind listener sockets
294
295The next step is to look up the binds in the profile, followed by binding
296aemp protocol listeners on all binds specified (it is possible and valid
297to have no binds, meaning that the node cannot be contacted form the
298outside. This means the node cannot talk to other nodes that also have no
299binds, but it can still talk to all "normal" nodes).
300
301If the profile does not specify a binds list, then a default of C<*> is
302used, meaning the node will bind on a dynamically-assigned port on every
303local IP address it finds.
304
305=item step 3, connect to seed nodes
306
307As the last step, the seed ID list from the profile is passed to the
308L<AnyEvent::MP::Global> module, which will then use it to keep
309connectivity with at least one node at any point in time.
310
311=back
312
313Example: become a distributed node using the local node name as profile.
314This should be the most common form of invocation for "daemon"-type nodes.
315
316 configure
317
318Example: become a semi-anonymous node. This form is often used for
319commandline clients.
320
321 configure nodeid => "myscript/%n/%u";
322
323Example: configure a node using a profile called seed, which is suitable
324for a seed node as it binds on all local addresses on a fixed port (4040,
325customary for aemp).
326
327 # use the aemp commandline utility
328 # aemp profile seed binds '*:4040'
329
330 # then use it
331 configure profile => "seed";
332
333 # or simply use aemp from the shell again:
334 # aemp run profile seed
335
336 # or provide a nicer-to-remember nodeid
337 # aemp run profile seed nodeid "$(hostname)"
161 338
162=item $SELF 339=item $SELF
163 340
164Contains the current port id while executing C<rcv> callbacks or C<psub> 341Contains the current port id while executing C<rcv> callbacks or C<psub>
165blocks. 342blocks.
166 343
167=item SELF, %SELF, @SELF... 344=item *SELF, SELF, %SELF, @SELF...
168 345
169Due to some quirks in how perl exports variables, it is impossible to 346Due to some quirks in how perl exports variables, it is impossible to
170just export C<$SELF>, all the symbols called C<SELF> are exported by this 347just export C<$SELF>, all the symbols named C<SELF> are exported by this
171module, but only C<$SELF> is currently used. 348module, but only C<$SELF> is currently used.
172 349
173=item snd $portid, type => @data 350=item snd $port, type => @data
174 351
175=item snd $portid, @msg 352=item snd $port, @msg
176 353
177Send the given message to the given port ID, which can identify either 354Send the given message to the given port, which can identify either a
178a local or a remote port, and can be either a string or soemthignt hat 355local or a remote port, and must be a port ID.
179stringifies a sa port ID (such as a port object :).
180 356
181While the message can be about anything, it is highly recommended to use a 357While the message can be almost anything, it is highly recommended to
182string as first element (a portid, or some word that indicates a request 358use a string as first element (a port ID, or some word that indicates a
183type etc.). 359request type etc.) and to consist if only simple perl values (scalars,
360arrays, hashes) - if you think you need to pass an object, think again.
184 361
185The message data effectively becomes read-only after a call to this 362The message data logically becomes read-only after a call to this
186function: modifying any argument is not allowed and can cause many 363function: modifying any argument (or values referenced by them) is
187problems. 364forbidden, as there can be considerable time between the call to C<snd>
365and the time the message is actually being serialised - in fact, it might
366never be copied as within the same process it is simply handed to the
367receiving port.
188 368
189The type of data you can transfer depends on the transport protocol: when 369The type of data you can transfer depends on the transport protocol: when
190JSON is used, then only strings, numbers and arrays and hashes consisting 370JSON is used, then only strings, numbers and arrays and hashes consisting
191of those are allowed (no objects). When Storable is used, then anything 371of those are allowed (no objects). When Storable is used, then anything
192that Storable can serialise and deserialise is allowed, and for the local 372that Storable can serialise and deserialise is allowed, and for the local
193node, anything can be passed. 373node, anything can be passed. Best rely only on the common denominator of
374these.
194 375
195=item kil $portid[, @reason] 376=item $local_port = port
196 377
197Kill the specified port with the given C<@reason>. 378Create a new local port object and returns its port ID. Initially it has
379no callbacks set and will throw an error when it receives messages.
198 380
199If no C<@reason> is specified, then the port is killed "normally" (linked 381=item $local_port = port { my @msg = @_ }
200ports will not be kileld, or even notified).
201 382
202Otherwise, linked ports get killed with the same reason (second form of 383Creates a new local port, and returns its ID. Semantically the same as
203C<mon>, see below). 384creating a port and calling C<rcv $port, $callback> on it.
204 385
205Runtime errors while evaluating C<rcv> callbacks or inside C<psub> blocks 386The block will be called for every message received on the port, with the
206will be reported as reason C<< die => $@ >>. 387global variable C<$SELF> set to the port ID. Runtime errors will cause the
388port to be C<kil>ed. The message will be passed as-is, no extra argument
389(i.e. no port ID) will be passed to the callback.
207 390
208Transport/communication errors are reported as C<< transport_error => 391If you want to stop/destroy the port, simply C<kil> it:
209$message >>.
210 392
211=item $guard = mon $portid, $cb->(@reason) 393 my $port = port {
212 394 my @msg = @_;
213=item $guard = mon $portid, $otherport 395 ...
214 396 kil $SELF;
215=item $guard = mon $portid, $otherport, @msg 397 };
216
217Monitor the given port and do something when the port is killed.
218
219In the first form, the callback is simply called with any number
220of C<@reason> elements (no @reason means that the port was deleted
221"normally"). Note also that I<< the callback B<must> never die >>, so use
222C<eval> if unsure.
223
224In the second form, the other port will be C<kil>'ed with C<@reason>, iff
225a @reason was specified, i.e. on "normal" kils nothing happens, while
226under all other conditions, the other port is killed with the same reason.
227
228In the last form, a message of the form C<@msg, @reason> will be C<snd>.
229
230Example: call a given callback when C<$port> is killed.
231
232 mon $port, sub { warn "port died because of <@_>\n" };
233
234Example: kill ourselves when C<$port> is killed abnormally.
235
236 mon $port, $self;
237
238Example: send us a restart message another C<$port> is killed.
239
240 mon $port, $self => "restart";
241 398
242=cut 399=cut
243 400
244sub mon { 401sub rcv($@);
245 my ($noderef, $port, $cb) = ((split /#/, shift, 2), shift);
246 402
247 my $node = $NODE{$noderef} || add_node $noderef; 403my $KILME = sub {
404 (my $tag = substr $_[0], 0, 30) =~ s/([\x20-\x7e])/./g;
405 kil $SELF, unhandled_message => "missing (tag or fallback) callback for message '$tag'";
406};
248 407
249 #TODO: ports must not be references 408sub port(;&) {
250 if (!ref $cb or "AnyEvent::MP::Port" eq ref $cb) { 409 my $id = $UNIQ . ++$ID;
410 my $port = "$NODE#$id";
411
412 rcv $port, shift || $KILME;
413
414 $port
415}
416
417=item rcv $local_port, $callback->(@msg)
418
419Replaces the default callback on the specified port. There is no way to
420remove the default callback: use C<sub { }> to disable it, or better
421C<kil> the port when it is no longer needed.
422
423The global C<$SELF> (exported by this module) contains C<$port> while
424executing the callback. Runtime errors during callback execution will
425result in the port being C<kil>ed.
426
427The default callback receives all messages not matched by a more specific
428C<tag> match.
429
430=item rcv $local_port, tag => $callback->(@msg_without_tag), ...
431
432Register (or replace) callbacks to be called on messages starting with the
433given tag on the given port (and return the port), or unregister it (when
434C<$callback> is C<$undef> or missing). There can only be one callback
435registered for each tag.
436
437The original message will be passed to the callback, after the first
438element (the tag) has been removed. The callback will use the same
439environment as the default callback (see above).
440
441Example: create a port and bind receivers on it in one go.
442
443 my $port = rcv port,
444 msg1 => sub { ... },
445 msg2 => sub { ... },
446 ;
447
448Example: create a port, bind receivers and send it in a message elsewhere
449in one go:
450
451 snd $otherport, reply =>
452 rcv port,
453 msg1 => sub { ... },
454 ...
455 ;
456
457Example: temporarily register a rcv callback for a tag matching some port
458(e.g. for an rpc reply) and unregister it after a message was received.
459
460 rcv $port, $otherport => sub {
461 my @reply = @_;
462
463 rcv $SELF, $otherport;
464 };
465
466=cut
467
468sub rcv($@) {
469 my $port = shift;
470 my ($nodeid, $portid) = split /#/, $port, 2;
471
472 $NODE{$nodeid} == $NODE{""}
473 or Carp::croak "$port: rcv can only be called on local ports, caught";
474
475 while (@_) {
251 if (@_) { 476 if (ref $_[0]) {
252 # send a kill info message 477 if (my $self = $PORT_DATA{$portid}) {
253 my (@msg) = ($cb, @_); 478 "AnyEvent::MP::Port" eq ref $self
254 $cb = sub { snd @msg, @_ }; 479 or Carp::croak "$port: rcv can only be called on message matching ports, caught";
480
481 $self->[0] = shift;
255 } else { 482 } else {
256 # simply kill other port 483 my $cb = shift;
257 my $port = $cb; 484 $PORT{$portid} = sub {
258 $cb = sub { kil $port, @_ if @_ }; 485 local $SELF = $port;
486 eval { &$cb }; _self_die if $@;
487 };
488 }
489 } elsif (defined $_[0]) {
490 my $self = $PORT_DATA{$portid} ||= do {
491 my $self = bless [$PORT{$portid} || sub { }, { }, $port], "AnyEvent::MP::Port";
492
493 $PORT{$portid} = sub {
494 local $SELF = $port;
495
496 if (my $cb = $self->[1]{$_[0]}) {
497 shift;
498 eval { &$cb }; _self_die if $@;
499 } else {
500 &{ $self->[0] };
501 }
502 };
503
504 $self
505 };
506
507 "AnyEvent::MP::Port" eq ref $self
508 or Carp::croak "$port: rcv can only be called on message matching ports, caught";
509
510 my ($tag, $cb) = splice @_, 0, 2;
511
512 if (defined $cb) {
513 $self->[1]{$tag} = $cb;
514 } else {
515 delete $self->[1]{$tag};
516 }
259 } 517 }
260 } 518 }
261 519
262 $node->monitor ($port, $cb);
263
264 defined wantarray
265 and AnyEvent::Util::guard { $node->unmonitor ($port, $cb) }
266}
267
268=item $guard = mon_guard $port, $ref, $ref...
269
270Monitors the given C<$port> and keeps the passed references. When the port
271is killed, the references will be freed.
272
273Optionally returns a guard that will stop the monitoring.
274
275This function is useful when you create e.g. timers or other watchers and
276want to free them when the port gets killed:
277
278 $port->rcv (start => sub {
279 my $timer; $timer = mon_guard $port, AE::timer 1, 1, sub {
280 undef $timer if 0.9 < rand;
281 });
282 });
283
284=cut
285
286sub mon_guard {
287 my ($port, @refs) = @_;
288
289 mon $port, sub { 0 && @refs }
290}
291
292=item lnk $port1, $port2
293
294Link two ports. This is simply a shorthand for:
295
296 mon $port1, $port2;
297 mon $port2, $port1;
298
299It means that if either one is killed abnormally, the other one gets
300killed as well.
301
302=item $local_port = port
303
304Create a new local port object that supports message matching.
305
306=item $portid = port { my @msg = @_; $finished }
307
308Creates a "mini port", that is, a very lightweight port without any
309pattern matching behind it, and returns its ID.
310
311The block will be called for every message received on the port. When the
312callback returns a true value its job is considered "done" and the port
313will be destroyed. Otherwise it will stay alive.
314
315The message will be passed as-is, no extra argument (i.e. no port id) will
316be passed to the callback.
317
318If you need the local port id in the callback, this works nicely:
319
320 my $port; $port = miniport {
321 snd $otherport, reply => $port;
322 };
323
324=cut
325
326sub port(;&) {
327 my $id = "$UNIQ." . $ID++;
328 my $port = "$NODE#$id";
329
330 if (@_) {
331 my $cb = shift;
332 $PORT{$id} = sub {
333 local $SELF = $port;
334 eval {
335 &$cb
336 and kil $id;
337 };
338 _self_die if $@;
339 };
340 } else {
341 my $self = bless {
342 id => "$NODE#$id",
343 }, "AnyEvent::MP::Port";
344
345 $PORT_DATA{$id} = $self;
346 $PORT{$id} = sub {
347 local $SELF = $port;
348
349 eval {
350 for (@{ $self->{rc0}{$_[0]} }) {
351 $_ && &{$_->[0]}
352 && undef $_;
353 }
354
355 for (@{ $self->{rcv}{$_[0]} }) {
356 $_ && [@_[1 .. @{$_->[1]}]] ~~ $_->[1]
357 && &{$_->[0]}
358 && undef $_;
359 }
360
361 for (@{ $self->{any} }) {
362 $_ && [@_[0 .. $#{$_->[1]}]] ~~ $_->[1]
363 && &{$_->[0]}
364 && undef $_;
365 }
366 };
367 _self_die if $@;
368 };
369 }
370
371 $port 520 $port
372} 521}
373 522
374=item reg $portid, $name 523=item peval $port, $coderef[, @args]
375 524
376Registers the given port under the name C<$name>. If the name already 525Evaluates the given C<$codref> within the contetx of C<$port>, that is,
377exists it is replaced. 526when the code throews an exception the C<$port> will be killed.
378 527
379A port can only be registered under one well known name. 528Any remaining args will be passed to the callback. Any return values will
529be returned to the caller.
380 530
381A port automatically becomes unregistered when it is killed. 531This is useful when you temporarily want to execute code in the context of
532a port.
533
534Example: create a port and run some initialisation code in it's context.
535
536 my $port = port { ... };
537
538 peval $port, sub {
539 init
540 or die "unable to init";
541 };
382 542
383=cut 543=cut
384 544
385sub reg(@) { 545sub peval($$) {
386 my ($portid, $name) = @_; 546 local $SELF = shift;
547 my $cb = shift;
387 548
388 $REG{$name} = $portid; 549 if (wantarray) {
389} 550 my @res = eval { &$cb };
390 551 _self_die if $@;
391=item rcv $portid, tagstring => $callback->(@msg), ... 552 @res
392
393=item rcv $portid, $smartmatch => $callback->(@msg), ...
394
395=item rcv $portid, [$smartmatch...] => $callback->(@msg), ...
396
397Register callbacks to be called on matching messages on the given port.
398
399The callback has to return a true value when its work is done, after
400which is will be removed, or a false value in which case it will stay
401registered.
402
403The global C<$SELF> (exported by this module) contains C<$portid> while
404executing the callback.
405
406Runtime errors wdurign callback execution will result in the port being
407C<kil>ed.
408
409If the match is an array reference, then it will be matched against the
410first elements of the message, otherwise only the first element is being
411matched.
412
413Any element in the match that is specified as C<_any_> (a function
414exported by this module) matches any single element of the message.
415
416While not required, it is highly recommended that the first matching
417element is a string identifying the message. The one-string-only match is
418also the most efficient match (by far).
419
420=cut
421
422sub rcv($@) {
423 my ($noderef, $port) = split /#/, shift, 2;
424
425 ($NODE{$noderef} || add_node $noderef) == $NODE{""}
426 or Carp::croak "$noderef#$port: rcv can only be called on local ports, caught";
427
428 my $self = $PORT_DATA{$port}
429 or Carp::croak "$noderef#$port: rcv can only be called on message matching ports, caught";
430
431 "AnyEvent::MP::Port" eq ref $self
432 or Carp::croak "$noderef#$port: rcv can only be called on message matching ports, caught";
433
434 while (@_) {
435 my ($match, $cb) = splice @_, 0, 2;
436
437 if (!ref $match) {
438 push @{ $self->{rc0}{$match} }, [$cb];
439 } elsif (("ARRAY" eq ref $match && !ref $match->[0])) {
440 my ($type, @match) = @$match;
441 @match
442 ? push @{ $self->{rcv}{$match->[0]} }, [$cb, \@match]
443 : push @{ $self->{rc0}{$match->[0]} }, [$cb];
444 } else { 553 } else {
445 push @{ $self->{any} }, [$cb, $match]; 554 my $res = eval { &$cb };
446 } 555 _self_die if $@;
556 $res
447 } 557 }
448} 558}
449 559
450=item $closure = psub { BLOCK } 560=item $closure = psub { BLOCK }
451 561
452Remembers C<$SELF> and creates a closure out of the BLOCK. When the 562Remembers C<$SELF> and creates a closure out of the BLOCK. When the
453closure is executed, sets up the environment in the same way as in C<rcv> 563closure is executed, sets up the environment in the same way as in C<rcv>
454callbacks, i.e. runtime errors will cause the port to get C<kil>ed. 564callbacks, i.e. runtime errors will cause the port to get C<kil>ed.
565
566The effect is basically as if it returned C<< sub { peval $SELF, sub {
567BLOCK }, @_ } >>.
455 568
456This is useful when you register callbacks from C<rcv> callbacks: 569This is useful when you register callbacks from C<rcv> callbacks:
457 570
458 rcv delayed_reply => sub { 571 rcv delayed_reply => sub {
459 my ($delay, @reply) = @_; 572 my ($delay, @reply) = @_;
483 $res 596 $res
484 } 597 }
485 } 598 }
486} 599}
487 600
601=item $guard = mon $port, $cb->(@reason) # call $cb when $port dies
602
603=item $guard = mon $port, $rcvport # kill $rcvport when $port dies
604
605=item $guard = mon $port # kill $SELF when $port dies
606
607=item $guard = mon $port, $rcvport, @msg # send a message when $port dies
608
609Monitor the given port and do something when the port is killed or
610messages to it were lost, and optionally return a guard that can be used
611to stop monitoring again.
612
613In the first form (callback), the callback is simply called with any
614number of C<@reason> elements (no @reason means that the port was deleted
615"normally"). Note also that I<< the callback B<must> never die >>, so use
616C<eval> if unsure.
617
618In the second form (another port given), the other port (C<$rcvport>)
619will be C<kil>'ed with C<@reason>, if a @reason was specified, i.e. on
620"normal" kils nothing happens, while under all other conditions, the other
621port is killed with the same reason.
622
623The third form (kill self) is the same as the second form, except that
624C<$rvport> defaults to C<$SELF>.
625
626In the last form (message), a message of the form C<@msg, @reason> will be
627C<snd>.
628
629Monitoring-actions are one-shot: once messages are lost (and a monitoring
630alert was raised), they are removed and will not trigger again.
631
632As a rule of thumb, monitoring requests should always monitor a port from
633a local port (or callback). The reason is that kill messages might get
634lost, just like any other message. Another less obvious reason is that
635even monitoring requests can get lost (for example, when the connection
636to the other node goes down permanently). When monitoring a port locally
637these problems do not exist.
638
639C<mon> effectively guarantees that, in the absence of hardware failures,
640after starting the monitor, either all messages sent to the port will
641arrive, or the monitoring action will be invoked after possible message
642loss has been detected. No messages will be lost "in between" (after
643the first lost message no further messages will be received by the
644port). After the monitoring action was invoked, further messages might get
645delivered again.
646
647Inter-host-connection timeouts and monitoring depend on the transport
648used. The only transport currently implemented is TCP, and AnyEvent::MP
649relies on TCP to detect node-downs (this can take 10-15 minutes on a
650non-idle connection, and usually around two hours for idle connections).
651
652This means that monitoring is good for program errors and cleaning up
653stuff eventually, but they are no replacement for a timeout when you need
654to ensure some maximum latency.
655
656Example: call a given callback when C<$port> is killed.
657
658 mon $port, sub { warn "port died because of <@_>\n" };
659
660Example: kill ourselves when C<$port> is killed abnormally.
661
662 mon $port;
663
664Example: send us a restart message when another C<$port> is killed.
665
666 mon $port, $self => "restart";
667
668=cut
669
670sub mon {
671 my ($nodeid, $port) = split /#/, shift, 2;
672
673 my $node = $NODE{$nodeid} || add_node $nodeid;
674
675 my $cb = @_ ? shift : $SELF || Carp::croak 'mon: called with one argument only, but $SELF not set,';
676
677 unless (ref $cb) {
678 if (@_) {
679 # send a kill info message
680 my (@msg) = ($cb, @_);
681 $cb = sub { snd @msg, @_ };
682 } else {
683 # simply kill other port
684 my $port = $cb;
685 $cb = sub { kil $port, @_ if @_ };
686 }
687 }
688
689 $node->monitor ($port, $cb);
690
691 defined wantarray
692 and ($cb += 0, Guard::guard { $node->unmonitor ($port, $cb) })
693}
694
695=item $guard = mon_guard $port, $ref, $ref...
696
697Monitors the given C<$port> and keeps the passed references. When the port
698is killed, the references will be freed.
699
700Optionally returns a guard that will stop the monitoring.
701
702This function is useful when you create e.g. timers or other watchers and
703want to free them when the port gets killed (note the use of C<psub>):
704
705 $port->rcv (start => sub {
706 my $timer; $timer = mon_guard $port, AE::timer 1, 1, psub {
707 undef $timer if 0.9 < rand;
708 });
709 });
710
711=cut
712
713sub mon_guard {
714 my ($port, @refs) = @_;
715
716 #TODO: mon-less form?
717
718 mon $port, sub { 0 && @refs }
719}
720
721=item kil $port[, @reason]
722
723Kill the specified port with the given C<@reason>.
724
725If no C<@reason> is specified, then the port is killed "normally" -
726monitor callback will be invoked, but the kil will not cause linked ports
727(C<mon $mport, $lport> form) to get killed.
728
729If a C<@reason> is specified, then linked ports (C<mon $mport, $lport>
730form) get killed with the same reason.
731
732Runtime errors while evaluating C<rcv> callbacks or inside C<psub> blocks
733will be reported as reason C<< die => $@ >>.
734
735Transport/communication errors are reported as C<< transport_error =>
736$message >>.
737
738Common idioms:
739
740 # silently remove yourself, do not kill linked ports
741 kil $SELF;
742
743 # report a failure in some detail
744 kil $SELF, failure_mode_1 => "it failed with too high temperature";
745
746 # do not waste much time with killing, just die when something goes wrong
747 open my $fh, "<file"
748 or die "file: $!";
749
750=item $port = spawn $node, $initfunc[, @initdata]
751
752Creates a port on the node C<$node> (which can also be a port ID, in which
753case it's the node where that port resides).
754
755The port ID of the newly created port is returned immediately, and it is
756possible to immediately start sending messages or to monitor the port.
757
758After the port has been created, the init function is called on the remote
759node, in the same context as a C<rcv> callback. This function must be a
760fully-qualified function name (e.g. C<MyApp::Chat::Server::init>). To
761specify a function in the main program, use C<::name>.
762
763If the function doesn't exist, then the node tries to C<require>
764the package, then the package above the package and so on (e.g.
765C<MyApp::Chat::Server>, C<MyApp::Chat>, C<MyApp>) until the function
766exists or it runs out of package names.
767
768The init function is then called with the newly-created port as context
769object (C<$SELF>) and the C<@initdata> values as arguments. It I<must>
770call one of the C<rcv> functions to set callbacks on C<$SELF>, otherwise
771the port might not get created.
772
773A common idiom is to pass a local port, immediately monitor the spawned
774port, and in the remote init function, immediately monitor the passed
775local port. This two-way monitoring ensures that both ports get cleaned up
776when there is a problem.
777
778C<spawn> guarantees that the C<$initfunc> has no visible effects on the
779caller before C<spawn> returns (by delaying invocation when spawn is
780called for the local node).
781
782Example: spawn a chat server port on C<$othernode>.
783
784 # this node, executed from within a port context:
785 my $server = spawn $othernode, "MyApp::Chat::Server::connect", $SELF;
786 mon $server;
787
788 # init function on C<$othernode>
789 sub connect {
790 my ($srcport) = @_;
791
792 mon $srcport;
793
794 rcv $SELF, sub {
795 ...
796 };
797 }
798
799=cut
800
801sub _spawn {
802 my $port = shift;
803 my $init = shift;
804
805 # rcv will create the actual port
806 local $SELF = "$NODE#$port";
807 eval {
808 &{ load_func $init }
809 };
810 _self_die if $@;
811}
812
813sub spawn(@) {
814 my ($nodeid, undef) = split /#/, shift, 2;
815
816 my $id = $RUNIQ . ++$ID;
817
818 $_[0] =~ /::/
819 or Carp::croak "spawn init function must be a fully-qualified name, caught";
820
821 snd_to_func $nodeid, "AnyEvent::MP::_spawn" => $id, @_;
822
823 "$nodeid#$id"
824}
825
826
827=item after $timeout, @msg
828
829=item after $timeout, $callback
830
831Either sends the given message, or call the given callback, after the
832specified number of seconds.
833
834This is simply a utility function that comes in handy at times - the
835AnyEvent::MP author is not convinced of the wisdom of having it, though,
836so it may go away in the future.
837
838=cut
839
840sub after($@) {
841 my ($timeout, @action) = @_;
842
843 my $t; $t = AE::timer $timeout, 0, sub {
844 undef $t;
845 ref $action[0]
846 ? $action[0]()
847 : snd @action;
848 };
849}
850
851#=item $cb2 = timeout $seconds, $cb[, @args]
852
853=item cal $port, @msg, $callback[, $timeout]
854
855A simple form of RPC - sends a message to the given C<$port> with the
856given contents (C<@msg>), but adds a reply port to the message.
857
858The reply port is created temporarily just for the purpose of receiving
859the reply, and will be C<kil>ed when no longer needed.
860
861A reply message sent to the port is passed to the C<$callback> as-is.
862
863If an optional time-out (in seconds) is given and it is not C<undef>,
864then the callback will be called without any arguments after the time-out
865elapsed and the port is C<kil>ed.
866
867If no time-out is given (or it is C<undef>), then the local port will
868monitor the remote port instead, so it eventually gets cleaned-up.
869
870Currently this function returns the temporary port, but this "feature"
871might go in future versions unless you can make a convincing case that
872this is indeed useful for something.
873
874=cut
875
876sub cal(@) {
877 my $timeout = ref $_[-1] ? undef : pop;
878 my $cb = pop;
879
880 my $port = port {
881 undef $timeout;
882 kil $SELF;
883 &$cb;
884 };
885
886 if (defined $timeout) {
887 $timeout = AE::timer $timeout, 0, sub {
888 undef $timeout;
889 kil $port;
890 $cb->();
891 };
892 } else {
893 mon $_[0], sub {
894 kil $port;
895 $cb->();
896 };
897 }
898
899 push @_, $port;
900 &snd;
901
902 $port
903}
904
488=back 905=back
489 906
490=head1 FUNCTIONS FOR NODES 907=head1 DISTRIBUTED DATABASE
491 908
909AnyEvent::MP comes with a simple distributed database. The database will
910be mirrored asynchronously on all global nodes. Other nodes bind to one
911of the global nodes for their needs. Every node has a "local database"
912which contains all the values that are set locally. All local databases
913are merged together to form the global database, which can be queried.
914
915The database structure is that of a two-level hash - the database hash
916contains hashes which contain values, similarly to a perl hash of hashes,
917i.e.:
918
919 $DATABASE{$family}{$subkey} = $value
920
921The top level hash key is called "family", and the second-level hash key
922is called "subkey" or simply "key".
923
924The family must be alphanumeric, i.e. start with a letter and consist
925of letters, digits, underscores and colons (C<[A-Za-z][A-Za-z0-9_:]*>,
926pretty much like Perl module names.
927
928As the family namespace is global, it is recommended to prefix family names
929with the name of the application or module using it.
930
931The subkeys must be non-empty strings, with no further restrictions.
932
933The values should preferably be strings, but other perl scalars should
934work as well (such as C<undef>, arrays and hashes).
935
936Every database entry is owned by one node - adding the same family/subkey
937combination on multiple nodes will not cause discomfort for AnyEvent::MP,
938but the result might be nondeterministic, i.e. the key might have
939different values on different nodes.
940
941Different subkeys in the same family can be owned by different nodes
942without problems, and in fact, this is the common method to create worker
943pools. For example, a worker port for image scaling might do this:
944
945 db_set my_image_scalers => $port;
946
947And clients looking for an image scaler will want to get the
948C<my_image_scalers> keys from time to time:
949
950 db_keys my_image_scalers => sub {
951 @ports = @{ $_[0] };
952 };
953
954Or better yet, they want to monitor the database family, so they always
955have a reasonable up-to-date copy:
956
957 db_mon my_image_scalers => sub {
958 @ports = keys %{ $_[0] };
959 };
960
961In general, you can set or delete single subkeys, but query and monitor
962whole families only.
963
964If you feel the need to monitor or query a single subkey, try giving it
965it's own family.
966
492=over 4 967=over
493 968
494=item become_public $noderef 969=item db_set $family => $subkey [=> $value]
495 970
496Tells the node to become a public node, i.e. reachable from other nodes. 971Sets (or replaces) a key to the database - if C<$value> is omitted,
972C<undef> is used instead.
497 973
498The first argument is the (unresolved) node reference of the local node 974=item db_del $family => $subkey...
499(if missing then the empty string is used).
500 975
501It is quite common to not specify anything, in which case the local node 976Deletes one or more subkeys from the database family.
502tries to listen on the default port, or to only specify a port number, in 977
503which case AnyEvent::MP tries to guess the local addresses. 978=item $guard = db_reg $family => $subkey [=> $value]
979
980Sets the key on the database and returns a guard. When the guard is
981destroyed, the key is deleted from the database. If C<$value> is missing,
982then C<undef> is used.
983
984=item db_family $family => $cb->(\%familyhash)
985
986Queries the named database C<$family> and call the callback with the
987family represented as a hash. You can keep and freely modify the hash.
988
989=item db_keys $family => $cb->(\@keys)
990
991Same as C<db_family>, except it only queries the family I<subkeys> and passes
992them as array reference to the callback.
993
994=item db_values $family => $cb->(\@values)
995
996Same as C<db_family>, except it only queries the family I<values> and passes them
997as array reference to the callback.
998
999=item $guard = db_mon $family => $cb->($familyhash, \@added, \@changed, \@deleted)
1000
1001Creates a monitor on the given database family. Each time a key is set
1002or or is deleted the callback is called with a hash containing the
1003database family and three lists of added, changed and deleted subkeys,
1004respectively. If no keys have changed then the array reference might be
1005C<undef> or even missing.
1006
1007If not called in void context, a guard object is returned that, when
1008destroyed, stops the monitor.
1009
1010The family hash reference and the key arrays belong to AnyEvent::MP and
1011B<must not be modified or stored> by the callback. When in doubt, make a
1012copy.
1013
1014As soon as possible after the monitoring starts, the callback will be
1015called with the intiial contents of the family, even if it is empty,
1016i.e. there will always be a timely call to the callback with the current
1017contents.
1018
1019It is possible that the callback is called with a change event even though
1020the subkey is already present and the value has not changed.
1021
1022The monitoring stops when the guard object is destroyed.
1023
1024Example: on every change to the family "mygroup", print out all keys.
1025
1026 my $guard = db_mon mygroup => sub {
1027 my ($family, $a, $c, $d) = @_;
1028 print "mygroup members: ", (join " ", keys %$family), "\n";
1029 };
1030
1031Exmaple: wait until the family "My::Module::workers" is non-empty.
1032
1033 my $guard; $guard = db_mon My::Module::workers => sub {
1034 my ($family, $a, $c, $d) = @_;
1035 return unless %$family;
1036 undef $guard;
1037 print "My::Module::workers now nonempty\n";
1038 };
1039
1040Example: print all changes to the family "AnyRvent::Fantasy::Module".
1041
1042 my $guard = db_mon AnyRvent::Fantasy::Module => sub {
1043 my ($family, $a, $c, $d) = @_;
1044
1045 print "+$_=$family->{$_}\n" for @$a;
1046 print "*$_=$family->{$_}\n" for @$c;
1047 print "-$_=$family->{$_}\n" for @$d;
1048 };
504 1049
505=cut 1050=cut
506 1051
507=back 1052=back
508 1053
509=head1 NODE MESSAGES
510
511Nodes understand the following messages sent to them. Many of them take
512arguments called C<@reply>, which will simply be used to compose a reply
513message - C<$reply[0]> is the port to reply to, C<$reply[1]> the type and
514the remaining arguments are simply the message data.
515
516While other messages exist, they are not public and subject to change.
517
518=over 4
519
520=cut
521
522=item lookup => $name, @reply
523
524Replies with the port ID of the specified well-known port, or C<undef>.
525
526=item devnull => ...
527
528Generic data sink/CPU heat conversion.
529
530=item relay => $port, @msg
531
532Simply forwards the message to the given port.
533
534=item eval => $string[ @reply]
535
536Evaluates the given string. If C<@reply> is given, then a message of the
537form C<@reply, $@, @evalres> is sent.
538
539Example: crash another node.
540
541 snd $othernode, eval => "exit";
542
543=item time => @reply
544
545Replies the the current node time to C<@reply>.
546
547Example: tell the current node to send the current time to C<$myport> in a
548C<timereply> message.
549
550 snd $NODE, time => $myport, timereply => 1, 2;
551 # => snd $myport, timereply => 1, 2, <time>
552
553=back
554
555=head1 AnyEvent::MP vs. Distributed Erlang 1054=head1 AnyEvent::MP vs. Distributed Erlang
556 1055
557AnyEvent::MP got lots of its ideas from distributed erlang (erlang node 1056AnyEvent::MP got lots of its ideas from distributed Erlang (Erlang node
558== aemp node, erlang process == aemp port), so many of the documents and 1057== aemp node, Erlang process == aemp port), so many of the documents and
559programming techniques employed by erlang apply to AnyEvent::MP. Here is a 1058programming techniques employed by Erlang apply to AnyEvent::MP. Here is a
560sample: 1059sample:
561 1060
562 http://www.erlang.se/doc/programming_rules.shtml 1061 http://www.erlang.se/doc/programming_rules.shtml
563 http://erlang.org/doc/getting_started/part_frame.html # chapters 3 and 4 1062 http://erlang.org/doc/getting_started/part_frame.html # chapters 3 and 4
564 http://erlang.org/download/erlang-book-part1.pdf # chapters 5 and 6 1063 http://erlang.org/download/erlang-book-part1.pdf # chapters 5 and 6
566 1065
567Despite the similarities, there are also some important differences: 1066Despite the similarities, there are also some important differences:
568 1067
569=over 4 1068=over 4
570 1069
571=item * Node references contain the recipe on how to contact them. 1070=item * Node IDs are arbitrary strings in AEMP.
572 1071
573Erlang relies on special naming and DNS to work everywhere in the 1072Erlang relies on special naming and DNS to work everywhere in the same
574same way. AEMP relies on each node knowing it's own address(es), with 1073way. AEMP relies on each node somehow knowing its own address(es) (e.g. by
575convenience functionality. 1074configuration or DNS), and possibly the addresses of some seed nodes, but
1075will otherwise discover other nodes (and their IDs) itself.
576 1076
577This means that AEMP requires a less tightly controlled environment at the 1077=item * Erlang has a "remote ports are like local ports" philosophy, AEMP
578cost of longer node references and a slightly higher management overhead. 1078uses "local ports are like remote ports".
1079
1080The failure modes for local ports are quite different (runtime errors
1081only) then for remote ports - when a local port dies, you I<know> it dies,
1082when a connection to another node dies, you know nothing about the other
1083port.
1084
1085Erlang pretends remote ports are as reliable as local ports, even when
1086they are not.
1087
1088AEMP encourages a "treat remote ports differently" philosophy, with local
1089ports being the special case/exception, where transport errors cannot
1090occur.
579 1091
580=item * Erlang uses processes and a mailbox, AEMP does not queue. 1092=item * Erlang uses processes and a mailbox, AEMP does not queue.
581 1093
582Erlang uses processes that selctively receive messages, and therefore 1094Erlang uses processes that selectively receive messages out of order, and
583needs a queue. AEMP is event based, queuing messages would serve no useful 1095therefore needs a queue. AEMP is event based, queuing messages would serve
584purpose. 1096no useful purpose. For the same reason the pattern-matching abilities
1097of AnyEvent::MP are more limited, as there is little need to be able to
1098filter messages without dequeuing them.
585 1099
586(But see L<Coro::MP> for a more erlang-like process model on top of AEMP). 1100This is not a philosophical difference, but simply stems from AnyEvent::MP
1101being event-based, while Erlang is process-based.
1102
1103You cna have a look at L<Coro::MP> for a more Erlang-like process model on
1104top of AEMP and Coro threads.
587 1105
588=item * Erlang sends are synchronous, AEMP sends are asynchronous. 1106=item * Erlang sends are synchronous, AEMP sends are asynchronous.
589 1107
590Sending messages in erlang is synchronous and blocks the process. AEMP 1108Sending messages in Erlang is synchronous and blocks the process until
591sends are immediate, connection establishment is handled in the 1109a conenction has been established and the message sent (and so does not
592background. 1110need a queue that can overflow). AEMP sends return immediately, connection
1111establishment is handled in the background.
593 1112
594=item * Erlang can silently lose messages, AEMP cannot. 1113=item * Erlang suffers from silent message loss, AEMP does not.
595 1114
596Erlang makes few guarantees on messages delivery - messages can get lost 1115Erlang implements few guarantees on messages delivery - messages can get
597without any of the processes realising it (i.e. you send messages a, b, 1116lost without any of the processes realising it (i.e. you send messages a,
598and c, and the other side only receives messages a and c). 1117b, and c, and the other side only receives messages a and c).
599 1118
600AEMP guarantees correct ordering, and the guarantee that there are no 1119AEMP guarantees (modulo hardware errors) correct ordering, and the
1120guarantee that after one message is lost, all following ones sent to the
1121same port are lost as well, until monitoring raises an error, so there are
601holes in the message sequence. 1122no silent "holes" in the message sequence.
602 1123
603=item * In erlang, processes can be declared dead and later be found to be 1124If you want your software to be very reliable, you have to cope with
604alive. 1125corrupted and even out-of-order messages in both Erlang and AEMP. AEMP
605 1126simply tries to work better in common error cases, such as when a network
606In erlang it can happen that a monitored process is declared dead and 1127link goes down.
607linked processes get killed, but later it turns out that the process is
608still alive - and can receive messages.
609
610In AEMP, when port monitoring detects a port as dead, then that port will
611eventually be killed - it cannot happen that a node detects a port as dead
612and then later sends messages to it, finding it is still alive.
613 1128
614=item * Erlang can send messages to the wrong port, AEMP does not. 1129=item * Erlang can send messages to the wrong port, AEMP does not.
615 1130
616In erlang it is quite possible that a node that restarts reuses a process 1131In Erlang it is quite likely that a node that restarts reuses an Erlang
617ID known to other nodes for a completely different process, causing 1132process ID known to other nodes for a completely different process,
618messages destined for that process to end up in an unrelated process. 1133causing messages destined for that process to end up in an unrelated
1134process.
619 1135
620AEMP never reuses port IDs, so old messages or old port IDs floating 1136AEMP does not reuse port IDs, so old messages or old port IDs floating
621around in the network will not be sent to an unrelated port. 1137around in the network will not be sent to an unrelated port.
622 1138
623=item * Erlang uses unprotected connections, AEMP uses secure 1139=item * Erlang uses unprotected connections, AEMP uses secure
624authentication and can use TLS. 1140authentication and can use TLS.
625 1141
626AEMP can use a proven protocol - SSL/TLS - to protect connections and 1142AEMP can use a proven protocol - TLS - to protect connections and
627securely authenticate nodes. 1143securely authenticate nodes.
628 1144
629=item * The AEMP protocol is optimised for both text-based and binary 1145=item * The AEMP protocol is optimised for both text-based and binary
630communications. 1146communications.
631 1147
632The AEMP protocol, unlike the erlang protocol, supports both 1148The AEMP protocol, unlike the Erlang protocol, supports both programming
633language-independent text-only protocols (good for debugging) and binary, 1149language independent text-only protocols (good for debugging), and binary,
634language-specific serialisers (e.g. Storable). 1150language-specific serialisers (e.g. Storable). By default, unless TLS is
1151used, the protocol is actually completely text-based.
635 1152
636It has also been carefully designed to be implementable in other languages 1153It has also been carefully designed to be implementable in other languages
637with a minimum of work while gracefully degrading fucntionality to make the 1154with a minimum of work while gracefully degrading functionality to make the
638protocol simple. 1155protocol simple.
639 1156
1157=item * AEMP has more flexible monitoring options than Erlang.
1158
1159In Erlang, you can chose to receive I<all> exit signals as messages or
1160I<none>, there is no in-between, so monitoring single Erlang processes is
1161difficult to implement.
1162
1163Monitoring in AEMP is more flexible than in Erlang, as one can choose
1164between automatic kill, exit message or callback on a per-port basis.
1165
1166=item * Erlang tries to hide remote/local connections, AEMP does not.
1167
1168Monitoring in Erlang is not an indicator of process death/crashes, in the
1169same way as linking is (except linking is unreliable in Erlang).
1170
1171In AEMP, you don't "look up" registered port names or send to named ports
1172that might or might not be persistent. Instead, you normally spawn a port
1173on the remote node. The init function monitors you, and you monitor the
1174remote port. Since both monitors are local to the node, they are much more
1175reliable (no need for C<spawn_link>).
1176
1177This also saves round-trips and avoids sending messages to the wrong port
1178(hard to do in Erlang).
1179
640=back 1180=back
641 1181
1182=head1 RATIONALE
1183
1184=over 4
1185
1186=item Why strings for port and node IDs, why not objects?
1187
1188We considered "objects", but found that the actual number of methods
1189that can be called are quite low. Since port and node IDs travel over
1190the network frequently, the serialising/deserialising would add lots of
1191overhead, as well as having to keep a proxy object everywhere.
1192
1193Strings can easily be printed, easily serialised etc. and need no special
1194procedures to be "valid".
1195
1196And as a result, a port with just a default receiver consists of a single
1197code reference stored in a global hash - it can't become much cheaper.
1198
1199=item Why favour JSON, why not a real serialising format such as Storable?
1200
1201In fact, any AnyEvent::MP node will happily accept Storable as framing
1202format, but currently there is no way to make a node use Storable by
1203default (although all nodes will accept it).
1204
1205The default framing protocol is JSON because a) JSON::XS is many times
1206faster for small messages and b) most importantly, after years of
1207experience we found that object serialisation is causing more problems
1208than it solves: Just like function calls, objects simply do not travel
1209easily over the network, mostly because they will always be a copy, so you
1210always have to re-think your design.
1211
1212Keeping your messages simple, concentrating on data structures rather than
1213objects, will keep your messages clean, tidy and efficient.
1214
1215=back
1216
642=head1 SEE ALSO 1217=head1 SEE ALSO
1218
1219L<AnyEvent::MP::Intro> - a gentle introduction.
1220
1221L<AnyEvent::MP::Kernel> - more, lower-level, stuff.
1222
1223L<AnyEvent::MP::Global> - network maintenance and port groups, to find
1224your applications.
1225
1226L<AnyEvent::MP::DataConn> - establish data connections between nodes.
1227
1228L<AnyEvent::MP::LogCatcher> - simple service to display log messages from
1229all nodes.
643 1230
644L<AnyEvent>. 1231L<AnyEvent>.
645 1232
646=head1 AUTHOR 1233=head1 AUTHOR
647 1234

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines