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

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines