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.49 by root, Thu Aug 13 15:29:58 2009 UTC vs.
Revision 1.142 by root, Fri Mar 23 13:44:01 2012 UTC

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

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines