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.30 by root, Tue Aug 4 23:35:51 2009 UTC vs.
Revision 1.132 by root, Sat Mar 10 20:34:11 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 its 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 {
394 my @msg = @_;
395 ...
396 kil $SELF;
397 };
212 398
213=item $guard = mon $portid, $otherport 399=cut
214 400
215=item $guard = mon $portid, $otherport, @msg 401sub rcv($@);
216 402
403my $KILME = sub {
404 die "received message on port without callback";
405};
406
407sub port(;&) {
408 my $id = $UNIQ . ++$ID;
409 my $port = "$NODE#$id";
410
411 rcv $port, shift || $KILME;
412
413 $port
414}
415
416=item rcv $local_port, $callback->(@msg)
417
418Replaces the default callback on the specified port. There is no way to
419remove the default callback: use C<sub { }> to disable it, or better
420C<kil> the port when it is no longer needed.
421
422The global C<$SELF> (exported by this module) contains C<$port> while
423executing the callback. Runtime errors during callback execution will
424result in the port being C<kil>ed.
425
426The default callback received all messages not matched by a more specific
427C<tag> match.
428
429=item rcv $local_port, tag => $callback->(@msg_without_tag), ...
430
431Register (or replace) callbacks to be called on messages starting with the
432given tag on the given port (and return the port), or unregister it (when
433C<$callback> is C<$undef> or missing). There can only be one callback
434registered for each tag.
435
436The original message will be passed to the callback, after the first
437element (the tag) has been removed. The callback will use the same
438environment as the default callback (see above).
439
440Example: create a port and bind receivers on it in one go.
441
442 my $port = rcv port,
443 msg1 => sub { ... },
444 msg2 => sub { ... },
445 ;
446
447Example: create a port, bind receivers and send it in a message elsewhere
448in one go:
449
450 snd $otherport, reply =>
451 rcv port,
452 msg1 => sub { ... },
453 ...
454 ;
455
456Example: temporarily register a rcv callback for a tag matching some port
457(e.g. for an rpc reply) and unregister it after a message was received.
458
459 rcv $port, $otherport => sub {
460 my @reply = @_;
461
462 rcv $SELF, $otherport;
463 };
464
465=cut
466
467sub rcv($@) {
468 my $port = shift;
469 my ($nodeid, $portid) = split /#/, $port, 2;
470
471 $NODE{$nodeid} == $NODE{""}
472 or Carp::croak "$port: rcv can only be called on local ports, caught";
473
474 while (@_) {
475 if (ref $_[0]) {
476 if (my $self = $PORT_DATA{$portid}) {
477 "AnyEvent::MP::Port" eq ref $self
478 or Carp::croak "$port: rcv can only be called on message matching ports, caught";
479
480 $self->[0] = shift;
481 } else {
482 my $cb = shift;
483 $PORT{$portid} = sub {
484 local $SELF = $port;
485 eval { &$cb }; _self_die if $@;
486 };
487 }
488 } elsif (defined $_[0]) {
489 my $self = $PORT_DATA{$portid} ||= do {
490 my $self = bless [$PORT{$portid} || sub { }, { }, $port], "AnyEvent::MP::Port";
491
492 $PORT{$portid} = sub {
493 local $SELF = $port;
494
495 if (my $cb = $self->[1]{$_[0]}) {
496 shift;
497 eval { &$cb }; _self_die if $@;
498 } else {
499 &{ $self->[0] };
500 }
501 };
502
503 $self
504 };
505
506 "AnyEvent::MP::Port" eq ref $self
507 or Carp::croak "$port: rcv can only be called on message matching ports, caught";
508
509 my ($tag, $cb) = splice @_, 0, 2;
510
511 if (defined $cb) {
512 $self->[1]{$tag} = $cb;
513 } else {
514 delete $self->[1]{$tag};
515 }
516 }
517 }
518
519 $port
520}
521
522=item peval $port, $coderef[, @args]
523
524Evaluates the given C<$codref> within the contetx of C<$port>, that is,
525when the code throews an exception the C<$port> will be killed.
526
527Any remaining args will be passed to the callback. Any return values will
528be returned to the caller.
529
530This is useful when you temporarily want to execute code in the context of
531a port.
532
533Example: create a port and run some initialisation code in it's context.
534
535 my $port = port { ... };
536
537 peval $port, sub {
538 init
539 or die "unable to init";
540 };
541
542=cut
543
544sub peval($$) {
545 local $SELF = shift;
546 my $cb = shift;
547
548 if (wantarray) {
549 my @res = eval { &$cb };
550 _self_die if $@;
551 @res
552 } else {
553 my $res = eval { &$cb };
554 _self_die if $@;
555 $res
556 }
557}
558
559=item $closure = psub { BLOCK }
560
561Remembers C<$SELF> and creates a closure out of the BLOCK. When the
562closure is executed, sets up the environment in the same way as in C<rcv>
563callbacks, i.e. runtime errors will cause the port to get C<kil>ed.
564
565The effect is basically as if it returned C<< sub { peval $SELF, sub {
566BLOCK }, @_ } >>.
567
568This is useful when you register callbacks from C<rcv> callbacks:
569
570 rcv delayed_reply => sub {
571 my ($delay, @reply) = @_;
572 my $timer = AE::timer $delay, 0, psub {
573 snd @reply, $SELF;
574 };
575 };
576
577=cut
578
579sub psub(&) {
580 my $cb = shift;
581
582 my $port = $SELF
583 or Carp::croak "psub can only be called from within rcv or psub callbacks, not";
584
585 sub {
586 local $SELF = $port;
587
588 if (wantarray) {
589 my @res = eval { &$cb };
590 _self_die if $@;
591 @res
592 } else {
593 my $res = eval { &$cb };
594 _self_die if $@;
595 $res
596 }
597 }
598}
599
600=item $guard = mon $port, $cb->(@reason) # call $cb when $port dies
601
602=item $guard = mon $port, $rcvport # kill $rcvport when $port dies
603
604=item $guard = mon $port # kill $SELF when $port dies
605
606=item $guard = mon $port, $rcvport, @msg # send a message when $port dies
607
217Monitor the given port and do something when the port is killed. 608Monitor the given port and do something when the port is killed or
609messages to it were lost, and optionally return a guard that can be used
610to stop monitoring again.
218 611
219In the first form, the callback is simply called with any number 612In the first form (callback), the callback is simply called with any
220of C<@reason> elements (no @reason means that the port was deleted 613number of 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 614"normally"). Note also that I<< the callback B<must> never die >>, so use
222C<eval> if unsure. 615C<eval> if unsure.
223 616
224In the second form, the other port will be C<kil>'ed with C<@reason>, iff 617In the second form (another port given), the other port (C<$rcvport>)
225a @reason was specified, i.e. on "normal" kils nothing happens, while 618will be C<kil>'ed with C<@reason>, if a @reason was specified, i.e. on
226under all other conditions, the other port is killed with the same reason. 619"normal" kils nothing happens, while under all other conditions, the other
620port is killed with the same reason.
227 621
622The third form (kill self) is the same as the second form, except that
623C<$rvport> defaults to C<$SELF>.
624
228In the last form, a message of the form C<@msg, @reason> will be C<snd>. 625In the last form (message), a message of the form C<@msg, @reason> will be
626C<snd>.
627
628Monitoring-actions are one-shot: once messages are lost (and a monitoring
629alert was raised), they are removed and will not trigger again.
630
631As a rule of thumb, monitoring requests should always monitor a port from
632a local port (or callback). The reason is that kill messages might get
633lost, just like any other message. Another less obvious reason is that
634even monitoring requests can get lost (for example, when the connection
635to the other node goes down permanently). When monitoring a port locally
636these problems do not exist.
637
638C<mon> effectively guarantees that, in the absence of hardware failures,
639after starting the monitor, either all messages sent to the port will
640arrive, or the monitoring action will be invoked after possible message
641loss has been detected. No messages will be lost "in between" (after
642the first lost message no further messages will be received by the
643port). After the monitoring action was invoked, further messages might get
644delivered again.
645
646Inter-host-connection timeouts and monitoring depend on the transport
647used. The only transport currently implemented is TCP, and AnyEvent::MP
648relies on TCP to detect node-downs (this can take 10-15 minutes on a
649non-idle connection, and usually around two hours for idle connections).
650
651This means that monitoring is good for program errors and cleaning up
652stuff eventually, but they are no replacement for a timeout when you need
653to ensure some maximum latency.
229 654
230Example: call a given callback when C<$port> is killed. 655Example: call a given callback when C<$port> is killed.
231 656
232 mon $port, sub { warn "port died because of <@_>\n" }; 657 mon $port, sub { warn "port died because of <@_>\n" };
233 658
234Example: kill ourselves when C<$port> is killed abnormally. 659Example: kill ourselves when C<$port> is killed abnormally.
235 660
236 mon $port, $self; 661 mon $port;
237 662
238Example: send us a restart message another C<$port> is killed. 663Example: send us a restart message when another C<$port> is killed.
239 664
240 mon $port, $self => "restart"; 665 mon $port, $self => "restart";
241 666
242=cut 667=cut
243 668
244sub mon { 669sub mon {
245 my ($noderef, $port) = split /#/, shift, 2; 670 my ($nodeid, $port) = split /#/, shift, 2;
246 671
247 my $node = $NODE{$noderef} || add_node $noderef; 672 my $node = $NODE{$nodeid} || add_node $nodeid;
248 673
249 my $cb = shift; 674 my $cb = @_ ? shift : $SELF || Carp::croak 'mon: called with one argument only, but $SELF not set,';
250 675
251 unless (ref $cb) { 676 unless (ref $cb) {
252 if (@_) { 677 if (@_) {
253 # send a kill info message 678 # send a kill info message
254 my (@msg) = ($cb, @_); 679 my (@msg) = ($cb, @_);
261 } 686 }
262 687
263 $node->monitor ($port, $cb); 688 $node->monitor ($port, $cb);
264 689
265 defined wantarray 690 defined wantarray
266 and AnyEvent::Util::guard { $node->unmonitor ($port, $cb) } 691 and ($cb += 0, Guard::guard { $node->unmonitor ($port, $cb) })
267} 692}
268 693
269=item $guard = mon_guard $port, $ref, $ref... 694=item $guard = mon_guard $port, $ref, $ref...
270 695
271Monitors the given C<$port> and keeps the passed references. When the port 696Monitors the given C<$port> and keeps the passed references. When the port
272is killed, the references will be freed. 697is killed, the references will be freed.
273 698
274Optionally returns a guard that will stop the monitoring. 699Optionally returns a guard that will stop the monitoring.
275 700
276This function is useful when you create e.g. timers or other watchers and 701This function is useful when you create e.g. timers or other watchers and
277want to free them when the port gets killed: 702want to free them when the port gets killed (note the use of C<psub>):
278 703
279 $port->rcv (start => sub { 704 $port->rcv (start => sub {
280 my $timer; $timer = mon_guard $port, AE::timer 1, 1, sub { 705 my $timer; $timer = mon_guard $port, AE::timer 1, 1, psub {
281 undef $timer if 0.9 < rand; 706 undef $timer if 0.9 < rand;
282 }); 707 });
283 }); 708 });
284 709
285=cut 710=cut
286 711
287sub mon_guard { 712sub mon_guard {
288 my ($port, @refs) = @_; 713 my ($port, @refs) = @_;
289 714
715 #TODO: mon-less form?
716
290 mon $port, sub { 0 && @refs } 717 mon $port, sub { 0 && @refs }
291} 718}
292 719
293=item lnk $port1, $port2 720=item kil $port[, @reason]
294 721
295Link two ports. This is simply a shorthand for: 722Kill the specified port with the given C<@reason>.
296 723
297 mon $port1, $port2; 724If no C<@reason> is specified, then the port is killed "normally" -
298 mon $port2, $port1; 725monitor callback will be invoked, but the kil will not cause linked ports
726(C<mon $mport, $lport> form) to get killed.
299 727
300It means that if either one is killed abnormally, the other one gets 728If a C<@reason> is specified, then linked ports (C<mon $mport, $lport>
301killed as well. 729form) get killed with the same reason.
302 730
303=item $local_port = port 731Runtime errors while evaluating C<rcv> callbacks or inside C<psub> blocks
732will be reported as reason C<< die => $@ >>.
304 733
305Create a new local port object that supports message matching. 734Transport/communication errors are reported as C<< transport_error =>
735$message >>.
306 736
307=item $portid = port { my @msg = @_; $finished } 737=cut
308 738
309Creates a "mini port", that is, a very lightweight port without any 739=item $port = spawn $node, $initfunc[, @initdata]
310pattern matching behind it, and returns its ID.
311 740
312The block will be called for every message received on the port. When the 741Creates a port on the node C<$node> (which can also be a port ID, in which
313callback returns a true value its job is considered "done" and the port 742case it's the node where that port resides).
314will be destroyed. Otherwise it will stay alive.
315 743
316The message will be passed as-is, no extra argument (i.e. no port id) will 744The port ID of the newly created port is returned immediately, and it is
317be passed to the callback. 745possible to immediately start sending messages or to monitor the port.
318 746
319If you need the local port id in the callback, this works nicely: 747After the port has been created, the init function is called on the remote
748node, in the same context as a C<rcv> callback. This function must be a
749fully-qualified function name (e.g. C<MyApp::Chat::Server::init>). To
750specify a function in the main program, use C<::name>.
320 751
321 my $port; $port = miniport { 752If the function doesn't exist, then the node tries to C<require>
322 snd $otherport, reply => $port; 753the package, then the package above the package and so on (e.g.
754C<MyApp::Chat::Server>, C<MyApp::Chat>, C<MyApp>) until the function
755exists or it runs out of package names.
756
757The init function is then called with the newly-created port as context
758object (C<$SELF>) and the C<@initdata> values as arguments. It I<must>
759call one of the C<rcv> functions to set callbacks on C<$SELF>, otherwise
760the port might not get created.
761
762A common idiom is to pass a local port, immediately monitor the spawned
763port, and in the remote init function, immediately monitor the passed
764local port. This two-way monitoring ensures that both ports get cleaned up
765when there is a problem.
766
767C<spawn> guarantees that the C<$initfunc> has no visible effects on the
768caller before C<spawn> returns (by delaying invocation when spawn is
769called for the local node).
770
771Example: spawn a chat server port on C<$othernode>.
772
773 # this node, executed from within a port context:
774 my $server = spawn $othernode, "MyApp::Chat::Server::connect", $SELF;
775 mon $server;
776
777 # init function on C<$othernode>
778 sub connect {
779 my ($srcport) = @_;
780
781 mon $srcport;
782
783 rcv $SELF, sub {
784 ...
785 };
786 }
787
788=cut
789
790sub _spawn {
791 my $port = shift;
792 my $init = shift;
793
794 # rcv will create the actual port
795 local $SELF = "$NODE#$port";
796 eval {
797 &{ load_func $init }
323 }; 798 };
799 _self_die if $@;
800}
801
802sub spawn(@) {
803 my ($nodeid, undef) = split /#/, shift, 2;
804
805 my $id = $RUNIQ . ++$ID;
806
807 $_[0] =~ /::/
808 or Carp::croak "spawn init function must be a fully-qualified name, caught";
809
810 snd_to_func $nodeid, "AnyEvent::MP::_spawn" => $id, @_;
811
812 "$nodeid#$id"
813}
814
815
816=item after $timeout, @msg
817
818=item after $timeout, $callback
819
820Either sends the given message, or call the given callback, after the
821specified number of seconds.
822
823This is simply a utility function that comes in handy at times - the
824AnyEvent::MP author is not convinced of the wisdom of having it, though,
825so it may go away in the future.
324 826
325=cut 827=cut
326 828
327sub port(;&) { 829sub after($@) {
328 my $id = "$UNIQ." . $ID++; 830 my ($timeout, @action) = @_;
329 my $port = "$NODE#$id";
330 831
331 if (@_) { 832 my $t; $t = AE::timer $timeout, 0, sub {
332 my $cb = shift; 833 undef $t;
333 $PORT{$id} = sub { 834 ref $action[0]
334 local $SELF = $port; 835 ? $action[0]()
335 eval { 836 : snd @action;
336 &$cb 837 };
337 and kil $id; 838}
338 }; 839
339 _self_die if $@; 840#=item $cb2 = timeout $seconds, $cb[, @args]
841
842=item cal $port, @msg, $callback[, $timeout]
843
844A simple form of RPC - sends a message to the given C<$port> with the
845given contents (C<@msg>), but adds a reply port to the message.
846
847The reply port is created temporarily just for the purpose of receiving
848the reply, and will be C<kil>ed when no longer needed.
849
850A reply message sent to the port is passed to the C<$callback> as-is.
851
852If an optional time-out (in seconds) is given and it is not C<undef>,
853then the callback will be called without any arguments after the time-out
854elapsed and the port is C<kil>ed.
855
856If no time-out is given (or it is C<undef>), then the local port will
857monitor the remote port instead, so it eventually gets cleaned-up.
858
859Currently this function returns the temporary port, but this "feature"
860might go in future versions unless you can make a convincing case that
861this is indeed useful for something.
862
863=cut
864
865sub cal(@) {
866 my $timeout = ref $_[-1] ? undef : pop;
867 my $cb = pop;
868
869 my $port = port {
870 undef $timeout;
871 kil $SELF;
872 &$cb;
873 };
874
875 if (defined $timeout) {
876 $timeout = AE::timer $timeout, 0, sub {
877 undef $timeout;
878 kil $port;
879 $cb->();
340 }; 880 };
341 } else { 881 } else {
342 my $self = bless { 882 mon $_[0], sub {
343 id => "$NODE#$id", 883 kil $port;
344 }, "AnyEvent::MP::Port"; 884 $cb->();
345
346 $PORT_DATA{$id} = $self;
347 $PORT{$id} = sub {
348 local $SELF = $port;
349
350 eval {
351 for (@{ $self->{rc0}{$_[0]} }) {
352 $_ && &{$_->[0]}
353 && undef $_;
354 }
355
356 for (@{ $self->{rcv}{$_[0]} }) {
357 $_ && [@_[1 .. @{$_->[1]}]] ~~ $_->[1]
358 && &{$_->[0]}
359 && undef $_;
360 }
361
362 for (@{ $self->{any} }) {
363 $_ && [@_[0 .. $#{$_->[1]}]] ~~ $_->[1]
364 && &{$_->[0]}
365 && undef $_;
366 }
367 };
368 _self_die if $@;
369 }; 885 };
370 } 886 }
371 887
888 push @_, $port;
889 &snd;
890
372 $port 891 $port
373} 892}
374 893
375=item reg $portid, $name 894=back
376 895
377Registers the given port under the name C<$name>. If the name already 896=head1 DISTRIBUTED DATABASE
378exists it is replaced.
379 897
380A port can only be registered under one well known name. 898AnyEvent::MP comes with a simple distributed database. The database will
899be mirrored asynchronously on all global nodes. Other nodes bind to one
900of the global nodes for their needs. Every node has a "local database"
901which contains all the values that are set locally. All local databases
902are merged together to form the global database, which can be queried.
381 903
382A port automatically becomes unregistered when it is killed. 904The database structure is that of a two-level hash - the database hash
905contains hashes which contain values, similarly to a perl hash of hashes,
906i.e.:
907
908 $DATABASE{$family}{$subkey} = $value
909
910The top level hash key is called "family", and the second-level hash key
911is called "subkey" or simply "key".
912
913The family must be alphanumeric, i.e. start with a letter and consist
914of letters, digits, underscores and colons (C<[A-Za-z][A-Za-z0-9_:]*>,
915pretty much like Perl module names.
916
917As the family namespace is global, it is recommended to prefix family names
918with the name of the application or module using it.
919
920The subkeys must be non-empty strings, with no further restrictions.
921
922The values should preferably be strings, but other perl scalars should
923work as well (such as C<undef>, arrays and hashes).
924
925Every database entry is owned by one node - adding the same family/subkey
926combination on multiple nodes will not cause discomfort for AnyEvent::MP,
927but the result might be nondeterministic, i.e. the key might have
928different values on different nodes.
929
930Different subkeys in the same family can be owned by different nodes
931without problems, and in fact, this is the common method to create worker
932pools. For example, a worker port for image scaling might do this:
933
934 db_set my_image_scalers => $port;
935
936And clients looking for an image scaler will want to get the
937C<my_image_scalers> keys from time to time:
938
939 db_keys my_image_scalers => sub {
940 @ports = @{ $_[0] };
941 };
942
943Or better yet, they want to monitor the database family, so they always
944have a reasonable up-to-date copy:
945
946 db_mon my_image_scalers => sub {
947 @ports = keys %{ $_[0] };
948 };
949
950In general, you can set or delete single subkeys, but query and monitor
951whole families only.
952
953If you feel the need to monitor or query a single subkey, try giving it
954it's own family.
955
956=over
957
958=item db_set $family => $subkey [=> $value]
959
960Sets (or replaces) a key to the database - if C<$value> is omitted,
961C<undef> is used instead.
962
963=item db_del $family => $subkey...
964
965Deletes one or more subkeys from the database family.
966
967=item $guard = db_reg $family => $subkey [=> $value]
968
969Sets the key on the database and returns a guard. When the guard is
970destroyed, the key is deleted from the database. If C<$value> is missing,
971then C<undef> is used.
972
973=item db_family $family => $cb->(\%familyhash)
974
975Queries the named database C<$family> and call the callback with the
976family represented as a hash. You can keep and freely modify the hash.
977
978=item db_keys $family => $cb->(\@keys)
979
980Same as C<db_family>, except it only queries the family I<subkeys> and passes
981them as array reference to the callback.
982
983=item db_values $family => $cb->(\@values)
984
985Same as C<db_family>, except it only queries the family I<values> and passes them
986as array reference to the callback.
987
988=item $guard = db_mon $family => $cb->($familyhash, \@added, \@changed, \@deleted)
989
990Creates a monitor on the given database family. Each time a key is set
991or or is deleted the callback is called with a hash containing the
992database family and three lists of added, changed and deleted subkeys,
993respectively. If no keys have changed then the array reference might be
994C<undef> or even missing.
995
996If not called in void context, a guard object is returned that, when
997destroyed, stops the monitor.
998
999The family hash reference and the key arrays belong to AnyEvent::MP and
1000B<must not be modified or stored> by the callback. When in doubt, make a
1001copy.
1002
1003As soon as possible after the monitoring starts, the callback will be
1004called with the intiial contents of the family, even if it is empty,
1005i.e. there will always be a timely call to the callback with the current
1006contents.
1007
1008It is possible that the callback is called with a change event even though
1009the subkey is already present and the value has not changed.
1010
1011The monitoring stops when the guard object is destroyed.
1012
1013Example: on every change to the family "mygroup", print out all keys.
1014
1015 my $guard = db_mon mygroup => sub {
1016 my ($family, $a, $c, $d) = @_;
1017 print "mygroup members: ", (join " ", keys %$family), "\n";
1018 };
1019
1020Exmaple: wait until the family "My::Module::workers" is non-empty.
1021
1022 my $guard; $guard = db_mon My::Module::workers => sub {
1023 my ($family, $a, $c, $d) = @_;
1024 return unless %$family;
1025 undef $guard;
1026 print "My::Module::workers now nonempty\n";
1027 };
1028
1029Example: print all changes to the family "AnyRvent::Fantasy::Module".
1030
1031 my $guard = db_mon AnyRvent::Fantasy::Module => sub {
1032 my ($family, $a, $c, $d) = @_;
1033
1034 print "+$_=$family->{$_}\n" for @$a;
1035 print "*$_=$family->{$_}\n" for @$c;
1036 print "-$_=$family->{$_}\n" for @$d;
1037 };
383 1038
384=cut 1039=cut
385 1040
386sub reg(@) {
387 my ($portid, $name) = @_;
388
389 $REG{$name} = $portid;
390}
391
392=item rcv $portid, tagstring => $callback->(@msg), ...
393
394=item rcv $portid, $smartmatch => $callback->(@msg), ...
395
396=item rcv $portid, [$smartmatch...] => $callback->(@msg), ...
397
398Register callbacks to be called on matching messages on the given port.
399
400The callback has to return a true value when its work is done, after
401which is will be removed, or a false value in which case it will stay
402registered.
403
404The global C<$SELF> (exported by this module) contains C<$portid> while
405executing the callback.
406
407Runtime errors wdurign callback execution will result in the port being
408C<kil>ed.
409
410If the match is an array reference, then it will be matched against the
411first elements of the message, otherwise only the first element is being
412matched.
413
414Any element in the match that is specified as C<_any_> (a function
415exported by this module) matches any single element of the message.
416
417While not required, it is highly recommended that the first matching
418element is a string identifying the message. The one-string-only match is
419also the most efficient match (by far).
420
421=cut
422
423sub rcv($@) {
424 my ($noderef, $port) = split /#/, shift, 2;
425
426 ($NODE{$noderef} || add_node $noderef) == $NODE{""}
427 or Carp::croak "$noderef#$port: rcv can only be called on local ports, caught";
428
429 my $self = $PORT_DATA{$port}
430 or Carp::croak "$noderef#$port: rcv can only be called on message matching ports, caught";
431
432 "AnyEvent::MP::Port" eq ref $self
433 or Carp::croak "$noderef#$port: rcv can only be called on message matching ports, caught";
434
435 while (@_) {
436 my ($match, $cb) = splice @_, 0, 2;
437
438 if (!ref $match) {
439 push @{ $self->{rc0}{$match} }, [$cb];
440 } elsif (("ARRAY" eq ref $match && !ref $match->[0])) {
441 my ($type, @match) = @$match;
442 @match
443 ? push @{ $self->{rcv}{$match->[0]} }, [$cb, \@match]
444 : push @{ $self->{rc0}{$match->[0]} }, [$cb];
445 } else {
446 push @{ $self->{any} }, [$cb, $match];
447 }
448 }
449}
450
451=item $closure = psub { BLOCK }
452
453Remembers C<$SELF> and creates a closure out of the BLOCK. When the
454closure is executed, sets up the environment in the same way as in C<rcv>
455callbacks, i.e. runtime errors will cause the port to get C<kil>ed.
456
457This is useful when you register callbacks from C<rcv> callbacks:
458
459 rcv delayed_reply => sub {
460 my ($delay, @reply) = @_;
461 my $timer = AE::timer $delay, 0, psub {
462 snd @reply, $SELF;
463 };
464 };
465
466=cut
467
468sub psub(&) {
469 my $cb = shift;
470
471 my $port = $SELF
472 or Carp::croak "psub can only be called from within rcv or psub callbacks, not";
473
474 sub {
475 local $SELF = $port;
476
477 if (wantarray) {
478 my @res = eval { &$cb };
479 _self_die if $@;
480 @res
481 } else {
482 my $res = eval { &$cb };
483 _self_die if $@;
484 $res
485 }
486 }
487}
488
489=back 1041=back
490 1042
491=head1 FUNCTIONS FOR NODES
492
493=over 4
494
495=item become_public $noderef
496
497Tells the node to become a public node, i.e. reachable from other nodes.
498
499The first argument is the (unresolved) node reference of the local node
500(if missing then the empty string is used).
501
502It is quite common to not specify anything, in which case the local node
503tries to listen on the default port, or to only specify a port number, in
504which case AnyEvent::MP tries to guess the local addresses.
505
506=cut
507
508=back
509
510=head1 NODE MESSAGES
511
512Nodes understand the following messages sent to them. Many of them take
513arguments called C<@reply>, which will simply be used to compose a reply
514message - C<$reply[0]> is the port to reply to, C<$reply[1]> the type and
515the remaining arguments are simply the message data.
516
517While other messages exist, they are not public and subject to change.
518
519=over 4
520
521=cut
522
523=item lookup => $name, @reply
524
525Replies with the port ID of the specified well-known port, or C<undef>.
526
527=item devnull => ...
528
529Generic data sink/CPU heat conversion.
530
531=item relay => $port, @msg
532
533Simply forwards the message to the given port.
534
535=item eval => $string[ @reply]
536
537Evaluates the given string. If C<@reply> is given, then a message of the
538form C<@reply, $@, @evalres> is sent.
539
540Example: crash another node.
541
542 snd $othernode, eval => "exit";
543
544=item time => @reply
545
546Replies the the current node time to C<@reply>.
547
548Example: tell the current node to send the current time to C<$myport> in a
549C<timereply> message.
550
551 snd $NODE, time => $myport, timereply => 1, 2;
552 # => snd $myport, timereply => 1, 2, <time>
553
554=back
555
556=head1 AnyEvent::MP vs. Distributed Erlang 1043=head1 AnyEvent::MP vs. Distributed Erlang
557 1044
558AnyEvent::MP got lots of its ideas from distributed erlang (erlang node 1045AnyEvent::MP got lots of its ideas from distributed Erlang (Erlang node
559== aemp node, erlang process == aemp port), so many of the documents and 1046== aemp node, Erlang process == aemp port), so many of the documents and
560programming techniques employed by erlang apply to AnyEvent::MP. Here is a 1047programming techniques employed by Erlang apply to AnyEvent::MP. Here is a
561sample: 1048sample:
562 1049
563 http://www.erlang.se/doc/programming_rules.shtml 1050 http://www.erlang.se/doc/programming_rules.shtml
564 http://erlang.org/doc/getting_started/part_frame.html # chapters 3 and 4 1051 http://erlang.org/doc/getting_started/part_frame.html # chapters 3 and 4
565 http://erlang.org/download/erlang-book-part1.pdf # chapters 5 and 6 1052 http://erlang.org/download/erlang-book-part1.pdf # chapters 5 and 6
567 1054
568Despite the similarities, there are also some important differences: 1055Despite the similarities, there are also some important differences:
569 1056
570=over 4 1057=over 4
571 1058
572=item * Node references contain the recipe on how to contact them. 1059=item * Node IDs are arbitrary strings in AEMP.
573 1060
574Erlang relies on special naming and DNS to work everywhere in the 1061Erlang relies on special naming and DNS to work everywhere in the same
575same way. AEMP relies on each node knowing it's own address(es), with 1062way. AEMP relies on each node somehow knowing its own address(es) (e.g. by
576convenience functionality. 1063configuration or DNS), and possibly the addresses of some seed nodes, but
1064will otherwise discover other nodes (and their IDs) itself.
577 1065
578This means that AEMP requires a less tightly controlled environment at the 1066=item * Erlang has a "remote ports are like local ports" philosophy, AEMP
579cost of longer node references and a slightly higher management overhead. 1067uses "local ports are like remote ports".
1068
1069The failure modes for local ports are quite different (runtime errors
1070only) then for remote ports - when a local port dies, you I<know> it dies,
1071when a connection to another node dies, you know nothing about the other
1072port.
1073
1074Erlang pretends remote ports are as reliable as local ports, even when
1075they are not.
1076
1077AEMP encourages a "treat remote ports differently" philosophy, with local
1078ports being the special case/exception, where transport errors cannot
1079occur.
580 1080
581=item * Erlang uses processes and a mailbox, AEMP does not queue. 1081=item * Erlang uses processes and a mailbox, AEMP does not queue.
582 1082
583Erlang uses processes that selctively receive messages, and therefore 1083Erlang uses processes that selectively receive messages out of order, and
584needs a queue. AEMP is event based, queuing messages would serve no useful 1084therefore needs a queue. AEMP is event based, queuing messages would serve
585purpose. 1085no useful purpose. For the same reason the pattern-matching abilities
1086of AnyEvent::MP are more limited, as there is little need to be able to
1087filter messages without dequeuing them.
586 1088
587(But see L<Coro::MP> for a more erlang-like process model on top of AEMP). 1089This is not a philosophical difference, but simply stems from AnyEvent::MP
1090being event-based, while Erlang is process-based.
1091
1092You cna have a look at L<Coro::MP> for a more Erlang-like process model on
1093top of AEMP and Coro threads.
588 1094
589=item * Erlang sends are synchronous, AEMP sends are asynchronous. 1095=item * Erlang sends are synchronous, AEMP sends are asynchronous.
590 1096
591Sending messages in erlang is synchronous and blocks the process. AEMP 1097Sending messages in Erlang is synchronous and blocks the process until
592sends are immediate, connection establishment is handled in the 1098a conenction has been established and the message sent (and so does not
593background. 1099need a queue that can overflow). AEMP sends return immediately, connection
1100establishment is handled in the background.
594 1101
595=item * Erlang can silently lose messages, AEMP cannot. 1102=item * Erlang suffers from silent message loss, AEMP does not.
596 1103
597Erlang makes few guarantees on messages delivery - messages can get lost 1104Erlang implements few guarantees on messages delivery - messages can get
598without any of the processes realising it (i.e. you send messages a, b, 1105lost without any of the processes realising it (i.e. you send messages a,
599and c, and the other side only receives messages a and c). 1106b, and c, and the other side only receives messages a and c).
600 1107
601AEMP guarantees correct ordering, and the guarantee that there are no 1108AEMP guarantees (modulo hardware errors) correct ordering, and the
1109guarantee that after one message is lost, all following ones sent to the
1110same port are lost as well, until monitoring raises an error, so there are
602holes in the message sequence. 1111no silent "holes" in the message sequence.
603 1112
604=item * In erlang, processes can be declared dead and later be found to be 1113If you want your software to be very reliable, you have to cope with
605alive. 1114corrupted and even out-of-order messages in both Erlang and AEMP. AEMP
606 1115simply tries to work better in common error cases, such as when a network
607In erlang it can happen that a monitored process is declared dead and 1116link goes down.
608linked processes get killed, but later it turns out that the process is
609still alive - and can receive messages.
610
611In AEMP, when port monitoring detects a port as dead, then that port will
612eventually be killed - it cannot happen that a node detects a port as dead
613and then later sends messages to it, finding it is still alive.
614 1117
615=item * Erlang can send messages to the wrong port, AEMP does not. 1118=item * Erlang can send messages to the wrong port, AEMP does not.
616 1119
617In erlang it is quite possible that a node that restarts reuses a process 1120In Erlang it is quite likely that a node that restarts reuses an Erlang
618ID known to other nodes for a completely different process, causing 1121process ID known to other nodes for a completely different process,
619messages destined for that process to end up in an unrelated process. 1122causing messages destined for that process to end up in an unrelated
1123process.
620 1124
621AEMP never reuses port IDs, so old messages or old port IDs floating 1125AEMP does not reuse port IDs, so old messages or old port IDs floating
622around in the network will not be sent to an unrelated port. 1126around in the network will not be sent to an unrelated port.
623 1127
624=item * Erlang uses unprotected connections, AEMP uses secure 1128=item * Erlang uses unprotected connections, AEMP uses secure
625authentication and can use TLS. 1129authentication and can use TLS.
626 1130
627AEMP can use a proven protocol - SSL/TLS - to protect connections and 1131AEMP can use a proven protocol - TLS - to protect connections and
628securely authenticate nodes. 1132securely authenticate nodes.
629 1133
630=item * The AEMP protocol is optimised for both text-based and binary 1134=item * The AEMP protocol is optimised for both text-based and binary
631communications. 1135communications.
632 1136
633The AEMP protocol, unlike the erlang protocol, supports both 1137The AEMP protocol, unlike the Erlang protocol, supports both programming
634language-independent text-only protocols (good for debugging) and binary, 1138language independent text-only protocols (good for debugging), and binary,
635language-specific serialisers (e.g. Storable). 1139language-specific serialisers (e.g. Storable). By default, unless TLS is
1140used, the protocol is actually completely text-based.
636 1141
637It has also been carefully designed to be implementable in other languages 1142It has also been carefully designed to be implementable in other languages
638with a minimum of work while gracefully degrading fucntionality to make the 1143with a minimum of work while gracefully degrading functionality to make the
639protocol simple. 1144protocol simple.
640 1145
1146=item * AEMP has more flexible monitoring options than Erlang.
1147
1148In Erlang, you can chose to receive I<all> exit signals as messages or
1149I<none>, there is no in-between, so monitoring single Erlang processes is
1150difficult to implement.
1151
1152Monitoring in AEMP is more flexible than in Erlang, as one can choose
1153between automatic kill, exit message or callback on a per-port basis.
1154
1155=item * Erlang tries to hide remote/local connections, AEMP does not.
1156
1157Monitoring in Erlang is not an indicator of process death/crashes, in the
1158same way as linking is (except linking is unreliable in Erlang).
1159
1160In AEMP, you don't "look up" registered port names or send to named ports
1161that might or might not be persistent. Instead, you normally spawn a port
1162on the remote node. The init function monitors you, and you monitor the
1163remote port. Since both monitors are local to the node, they are much more
1164reliable (no need for C<spawn_link>).
1165
1166This also saves round-trips and avoids sending messages to the wrong port
1167(hard to do in Erlang).
1168
641=back 1169=back
642 1170
1171=head1 RATIONALE
1172
1173=over 4
1174
1175=item Why strings for port and node IDs, why not objects?
1176
1177We considered "objects", but found that the actual number of methods
1178that can be called are quite low. Since port and node IDs travel over
1179the network frequently, the serialising/deserialising would add lots of
1180overhead, as well as having to keep a proxy object everywhere.
1181
1182Strings can easily be printed, easily serialised etc. and need no special
1183procedures to be "valid".
1184
1185And as a result, a port with just a default receiver consists of a single
1186code reference stored in a global hash - it can't become much cheaper.
1187
1188=item Why favour JSON, why not a real serialising format such as Storable?
1189
1190In fact, any AnyEvent::MP node will happily accept Storable as framing
1191format, but currently there is no way to make a node use Storable by
1192default (although all nodes will accept it).
1193
1194The default framing protocol is JSON because a) JSON::XS is many times
1195faster for small messages and b) most importantly, after years of
1196experience we found that object serialisation is causing more problems
1197than it solves: Just like function calls, objects simply do not travel
1198easily over the network, mostly because they will always be a copy, so you
1199always have to re-think your design.
1200
1201Keeping your messages simple, concentrating on data structures rather than
1202objects, will keep your messages clean, tidy and efficient.
1203
1204=back
1205
643=head1 SEE ALSO 1206=head1 SEE ALSO
1207
1208L<AnyEvent::MP::Intro> - a gentle introduction.
1209
1210L<AnyEvent::MP::Kernel> - more, lower-level, stuff.
1211
1212L<AnyEvent::MP::Global> - network maintenance and port groups, to find
1213your applications.
1214
1215L<AnyEvent::MP::DataConn> - establish data connections between nodes.
1216
1217L<AnyEvent::MP::LogCatcher> - simple service to display log messages from
1218all nodes.
644 1219
645L<AnyEvent>. 1220L<AnyEvent>.
646 1221
647=head1 AUTHOR 1222=head1 AUTHOR
648 1223

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines