ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/cvsroot/AnyEvent-MP/MP.pm
(Generate patch)

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

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines