[ViewVC] Diff of: cvs/AnyEvent-MP/MP.pm

Comparing AnyEvent-MP/MP.pm (file contents):
Revision 1.34 by root, Wed Aug 5 23:50:46 2009 UTC vs.
Revision 1.39 by root, Fri Aug 7 23:21:48 2009 UTC

…		…
8		8
9	$NODE # contains this node's noderef	9	$NODE # contains this node's noderef
10	NODE # returns this node's noderef	10	NODE # returns this node's noderef
11	NODE $port # returns the noderef of the port	11	NODE $port # returns the noderef of the port
12		12
		13	$SELF # receiving/own port id in rcv callbacks
		14
		15	# ports are message endpoints
		16
		17	# sending messages
13	snd $port, type => data...;	18	snd $port, type => data...;
		19	snd $port, @msg;
		20	snd @msg_with_first_element_being_a_port;
14		21
15	$SELF # receiving/own port id in rcv callbacks	22	# miniports
		23	my $miniport = port { my @msg = @_; 0 };
16		24
		25	# full ports
		26	my $port = port;
17	rcv $port, smartmatch => $cb->($port, @msg);	27	rcv $port, smartmatch => $cb->(@msg);
18
19	# examples:
20	rcv $port2, ping => sub { snd $_[0], "pong"; 0 };	28	rcv $port, ping => sub { snd $_[0], "pong"; 0 };
21	rcv $port1, pong => sub { warn "pong received\n" };	29	rcv $port, pong => sub { warn "pong received\n"; 0 };
22	snd $port2, ping => $port1;	30
		31	# remote ports
		32	my $port = spawn $node, $initfunc, @initdata;
23		33
24	# more, smarter, matches (_any_ is exported by this module)	34	# more, smarter, matches (_any_ is exported by this module)
25	rcv $port, [child_died => $pid] => sub { ...	35	rcv $port, [child_died => $pid] => sub { ...
26	rcv $port, [_any_, _any_, 3] => sub { .. $_[2] is 3	36	rcv $port, [_any_, _any_, 3] => sub { .. $_[2] is 3
		37
		38	# monitoring
		39	mon $port, $cb->(@msg) # callback is invoked on death
		40	mon $port, $otherport # kill otherport on abnormal death
		41	mon $port, $otherport, @msg # send message on death
27		42
28	=head1 DESCRIPTION	43	=head1 DESCRIPTION
29		44
30	This module (-family) implements a simple message passing framework.	45	This module (-family) implements a simple message passing framework.
31		46
…		…
104		119
105	our $VERSION = '0.1';	120	our $VERSION = '0.1';
106	our @EXPORT = qw(	121	our @EXPORT = qw(
107	NODE $NODE *SELF node_of _any_	122	NODE $NODE *SELF node_of _any_
108	resolve_node initialise_node	123	resolve_node initialise_node
109	snd rcv mon kil reg psub	124	snd rcv mon kil reg psub spawn
110	port	125	port
111	);	126	);
112		127
113	our $SELF;	128	our $SELF;
114		129
…		…
297	$port	312	$port
298	}	313	}
299		314
300	=item reg $port, $name	315	=item reg $port, $name
301		316
302	Registers the given port under the name C<$name>. If the name already	317	=item reg $name
303	exists it is replaced.	318
		319	Registers the given port (or C<$SELF><<< if missing) under the name
		320	C<$name>. If the name already exists it is replaced.
304		321
305	A port can only be registered under one well known name.	322	A port can only be registered under one well known name.
306		323
307	A port automatically becomes unregistered when it is killed.	324	A port automatically becomes unregistered when it is killed.
308		325
309	=cut	326	=cut
310		327
311	sub reg(@) {	328	sub reg(@) {
312	my ($port, $name) = @_;	329	my $port = @_ > 1 ? shift : $SELF \|\| Carp::croak 'reg: called with one argument only, but $SELF not set,';
313		330
314	$REG{$name} = $port;	331	$REG{$_[0]} = $port;
315	}	332	}
316		333
317	=item rcv $port, $callback->(@msg)	334	=item rcv $port, $callback->(@msg)
318		335
319	Replaces the callback on the specified miniport (after converting it to	336	Replaces the callback on the specified miniport (after converting it to
…		…
324	=item rcv $port, $smartmatch => $callback->(@msg), ...	341	=item rcv $port, $smartmatch => $callback->(@msg), ...
325		342
326	=item rcv $port, [$smartmatch...] => $callback->(@msg), ...	343	=item rcv $port, [$smartmatch...] => $callback->(@msg), ...
327		344
328	Register callbacks to be called on matching messages on the given full	345	Register callbacks to be called on matching messages on the given full
329	port (after converting it to one if required).	346	port (after converting it to one if required) and return the port.
330		347
331	The callback has to return a true value when its work is done, after	348	The callback has to return a true value when its work is done, after
332	which is will be removed, or a false value in which case it will stay	349	which is will be removed, or a false value in which case it will stay
333	registered.	350	registered.
334		351
335	The global C<$SELF> (exported by this module) contains C<$port> while	352	The global C<$SELF> (exported by this module) contains C<$port> while
336	executing the callback.	353	executing the callback.
337		354
338	Runtime errors wdurign callback execution will result in the port being	355	Runtime errors during callback execution will result in the port being
339	C<kil>ed.	356	C<kil>ed.
340		357
341	If the match is an array reference, then it will be matched against the	358	If the match is an array reference, then it will be matched against the
342	first elements of the message, otherwise only the first element is being	359	first elements of the message, otherwise only the first element is being
343	matched.	360	matched.
…		…
346	exported by this module) matches any single element of the message.	363	exported by this module) matches any single element of the message.
347		364
348	While not required, it is highly recommended that the first matching	365	While not required, it is highly recommended that the first matching
349	element is a string identifying the message. The one-string-only match is	366	element is a string identifying the message. The one-string-only match is
350	also the most efficient match (by far).	367	also the most efficient match (by far).
		368
		369	Example: create a port and bind receivers on it in one go.
		370
		371	my $port = rcv port,
		372	msg1 => sub { ...; 0 },
		373	msg2 => sub { ...; 0 },
		374	;
		375
		376	Example: create a port, bind receivers and send it in a message elsewhere
		377	in one go:
		378
		379	snd $otherport, reply =>
		380	rcv port,
		381	msg1 => sub { ...; 0 },
		382	...
		383	;
351		384
352	=cut	385	=cut
353		386
354	sub rcv($@) {	387	sub rcv($@) {
355	my $port = shift;	388	my $port = shift;
…		…
462	}	495	}
463	}	496	}
464		497
465	=item $guard = mon $port, $cb->(@reason)	498	=item $guard = mon $port, $cb->(@reason)
466		499
467	=item $guard = mon $port, $otherport	500	=item $guard = mon $port, $rcvport
468		501
		502	=item $guard = mon $port
		503
469	=item $guard = mon $port, $otherport, @msg	504	=item $guard = mon $port, $rcvport, @msg
470		505
471	Monitor the given port and do something when the port is killed.	506	Monitor the given port and do something when the port is killed, and
		507	optionally return a guard that can be used to stop monitoring again.
472		508
473	In the first form, the callback is simply called with any number	509	In the first form (callback), the callback is simply called with any
474	of C<@reason> elements (no @reason means that the port was deleted	510	number of C<@reason> elements (no @reason means that the port was deleted
475	"normally"). Note also that I<< the callback B<must> never die >>, so use	511	"normally"). Note also that I<< the callback B<must> never die >>, so use
476	C<eval> if unsure.	512	C<eval> if unsure.
477		513
478	In the second form, the other port will be C<kil>'ed with C<@reason>, iff	514	In the second form (another port given), the other port (C<$rcvport)
479	a @reason was specified, i.e. on "normal" kils nothing happens, while	515	will be C<kil>'ed with C<@reason>, iff a @reason was specified, i.e. on
480	under all other conditions, the other port is killed with the same reason.	516	"normal" kils nothing happens, while under all other conditions, the other
		517	port is killed with the same reason.
481		518
		519	The third form (kill self) is the same as the second form, except that
		520	C<$rvport> defaults to C<$SELF>.
		521
482	In the last form, a message of the form C<@msg, @reason> will be C<snd>.	522	In the last form (message), a message of the form C<@msg, @reason> will be
		523	C<snd>.
		524
		525	As a rule of thumb, monitoring requests should always monitor a port from
		526	a local port (or callback). The reason is that kill messages might get
		527	lost, just like any other message. Another less obvious reason is that
		528	even monitoring requests can get lost (for exmaple, when the connection
		529	to the other node goes down permanently). When monitoring a port locally
		530	these problems do not exist.
483		531
484	Example: call a given callback when C<$port> is killed.	532	Example: call a given callback when C<$port> is killed.
485		533
486	mon $port, sub { warn "port died because of <@_>\n" };	534	mon $port, sub { warn "port died because of <@_>\n" };
487		535
488	Example: kill ourselves when C<$port> is killed abnormally.	536	Example: kill ourselves when C<$port> is killed abnormally.
489		537
490	mon $port, $self;	538	mon $port;
491		539
492	Example: send us a restart message another C<$port> is killed.	540	Example: send us a restart message when another C<$port> is killed.
493		541
494	mon $port, $self => "restart";	542	mon $port, $self => "restart";
495		543
496	=cut	544	=cut
497		545
498	sub mon {	546	sub mon {
499	my ($noderef, $port) = split /#/, shift, 2;	547	my ($noderef, $port) = split /#/, shift, 2;
500		548
501	my $node = $NODE{$noderef} \|\| add_node $noderef;	549	my $node = $NODE{$noderef} \|\| add_node $noderef;
502		550
503	my $cb = shift;	551	my $cb = @_ ? $_[0] : $SELF \|\| Carp::croak 'mon: called with one argument only, but $SELF not set,';
504		552
505	unless (ref $cb) {	553	unless (ref $cb) {
506	if (@_) {	554	if (@_) {
507	# send a kill info message	555	# send a kill info message
508	my (@msg) = ($cb, @_);	556	my (@msg) = @_;
509	$cb = sub { snd @msg, @_ };	557	$cb = sub { snd @msg, @_ };
510	} else {	558	} else {
511	# simply kill other port	559	# simply kill other port
512	my $port = $cb;	560	my $port = $cb;
513	$cb = sub { kil $port, @_ if @_ };	561	$cb = sub { kil $port, @_ if @_ };
…		…
539	=cut	587	=cut
540		588
541	sub mon_guard {	589	sub mon_guard {
542	my ($port, @refs) = @_;	590	my ($port, @refs) = @_;
543		591
		592	#TODO: mon-less form?
		593
544	mon $port, sub { 0 && @refs }	594	mon $port, sub { 0 && @refs }
545	}	595	}
546		596
547	=item lnk $port1, $port2
548
549	Link two ports. This is simply a shorthand for:
550
551	mon $port1, $port2;
552	mon $port2, $port1;
553
554	It means that if either one is killed abnormally, the other one gets
555	killed as well.
556
557	=item kil $port[, @reason]	597	=item kil $port[, @reason]
558		598
559	Kill the specified port with the given C<@reason>.	599	Kill the specified port with the given C<@reason>.
560		600
561	If no C<@reason> is specified, then the port is killed "normally" (linked	601	If no C<@reason> is specified, then the port is killed "normally" (linked
…		…
567	Runtime errors while evaluating C<rcv> callbacks or inside C<psub> blocks	607	Runtime errors while evaluating C<rcv> callbacks or inside C<psub> blocks
568	will be reported as reason C<< die => $@ >>.	608	will be reported as reason C<< die => $@ >>.
569		609
570	Transport/communication errors are reported as C<< transport_error =>	610	Transport/communication errors are reported as C<< transport_error =>
571	$message >>.	611	$message >>.
		612
		613	=cut
		614
		615	=item $port = spawn $node, $initfunc[, @initdata]
		616
		617	Creates a port on the node C<$node> (which can also be a port ID, in which
		618	case it's the node where that port resides).
		619
		620	The port ID of the newly created port is return immediately, and it is
		621	permissible to immediately start sending messages or monitor the port.
		622
		623	After the port has been created, the init function is
		624	called. This function must be a fully-qualified function name
		625	(e.g. C<MyApp::Chat::Server::init>).
		626
		627	If the function doesn't exist, then the node tries to C<require>
		628	the package, then the package above the package and so on (e.g.
		629	C<MyApp::Chat::Server>, C<MyApp::Chat>, C<MyApp>) until the function
		630	exists or it runs out of package names.
		631
		632	The init function is then called with the newly-created port as context
		633	object (C<$SELF>) and the C<@initdata> values as arguments.
		634
		635	A common idiom is to pass your own port, monitor the spawned port, and
		636	in the init function, monitor the original port. This two-way monitoring
		637	ensures that both ports get cleaned up when there is a problem.
		638
		639	Example: spawn a chat server port on C<$othernode>.
		640
		641	# this node, executed from within a port context:
		642	my $server = spawn $othernode, "MyApp::Chat::Server::connect", $SELF;
		643	mon $server;
		644
		645	# init function on C<$othernode>
		646	sub connect {
		647	my ($srcport) = @_;
		648
		649	mon $srcport;
		650
		651	rcv $SELF, sub {
		652	...
		653	};
		654	}
		655
		656	=cut
		657
		658	sub _spawn {
		659	my $port = shift;
		660	my $init = shift;
		661
		662	local $SELF = "$NODE#$port";
		663	eval {
		664	&{ load_func $init }
		665	};
		666	_self_die if $@;
		667	}
		668
		669	sub spawn(@) {
		670	my ($noderef, undef) = split /#/, shift, 2;
		671
		672	my $id = "$RUNIQ." . $ID++;
		673
		674	$_[0] =~ /::/
		675	or Carp::croak "spawn init function must be a fully-qualified name, caught";
		676
		677	($NODE{$noderef} \|\| add_node $noderef)
		678	->send (["", "AnyEvent::MP::_spawn" => $id, @_]);
		679
		680	"$noderef#$id"
		681	}
572		682
573	=back	683	=back
574		684
575	=head1 NODE MESSAGES	685	=head1 NODE MESSAGES
576		686
…		…
618		728
619	=back	729	=back
620		730
621	=head1 AnyEvent::MP vs. Distributed Erlang	731	=head1 AnyEvent::MP vs. Distributed Erlang
622		732
623	AnyEvent::MP got lots of its ideas from distributed erlang (erlang node	733	AnyEvent::MP got lots of its ideas from distributed Erlang (Erlang node
624	== aemp node, erlang process == aemp port), so many of the documents and	734	== aemp node, Erlang process == aemp port), so many of the documents and
625	programming techniques employed by erlang apply to AnyEvent::MP. Here is a	735	programming techniques employed by Erlang apply to AnyEvent::MP. Here is a
626	sample:	736	sample:
627		737
628	http://www.erlang.se/doc/programming_rules.shtml	738	http://www.Erlang.se/doc/programming_rules.shtml
629	http://erlang.org/doc/getting_started/part_frame.html # chapters 3 and 4	739	http://Erlang.org/doc/getting_started/part_frame.html # chapters 3 and 4
630	http://erlang.org/download/erlang-book-part1.pdf # chapters 5 and 6	740	http://Erlang.org/download/Erlang-book-part1.pdf # chapters 5 and 6
631	http://erlang.org/download/armstrong_thesis_2003.pdf # chapters 4 and 5	741	http://Erlang.org/download/armstrong_thesis_2003.pdf # chapters 4 and 5
632		742
633	Despite the similarities, there are also some important differences:	743	Despite the similarities, there are also some important differences:
634		744
635	=over 4	745	=over 4
636		746
…		…
647		757
648	Erlang uses processes that selctively receive messages, and therefore	758	Erlang uses processes that selctively receive messages, and therefore
649	needs a queue. AEMP is event based, queuing messages would serve no useful	759	needs a queue. AEMP is event based, queuing messages would serve no useful
650	purpose.	760	purpose.
651		761
652	(But see L<Coro::MP> for a more erlang-like process model on top of AEMP).	762	(But see L<Coro::MP> for a more Erlang-like process model on top of AEMP).
653		763
654	=item * Erlang sends are synchronous, AEMP sends are asynchronous.	764	=item * Erlang sends are synchronous, AEMP sends are asynchronous.
655		765
656	Sending messages in erlang is synchronous and blocks the process. AEMP	766	Sending messages in Erlang is synchronous and blocks the process. AEMP
657	sends are immediate, connection establishment is handled in the	767	sends are immediate, connection establishment is handled in the
658	background.	768	background.
659		769
660	=item * Erlang can silently lose messages, AEMP cannot.	770	=item * Erlang can silently lose messages, AEMP cannot.
661		771
…		…
664	and c, and the other side only receives messages a and c).	774	and c, and the other side only receives messages a and c).
665		775
666	AEMP guarantees correct ordering, and the guarantee that there are no	776	AEMP guarantees correct ordering, and the guarantee that there are no
667	holes in the message sequence.	777	holes in the message sequence.
668		778
669	=item * In erlang, processes can be declared dead and later be found to be	779	=item * In Erlang, processes can be declared dead and later be found to be
670	alive.	780	alive.
671		781
672	In erlang it can happen that a monitored process is declared dead and	782	In Erlang it can happen that a monitored process is declared dead and
673	linked processes get killed, but later it turns out that the process is	783	linked processes get killed, but later it turns out that the process is
674	still alive - and can receive messages.	784	still alive - and can receive messages.
675		785
676	In AEMP, when port monitoring detects a port as dead, then that port will	786	In AEMP, when port monitoring detects a port as dead, then that port will
677	eventually be killed - it cannot happen that a node detects a port as dead	787	eventually be killed - it cannot happen that a node detects a port as dead
678	and then later sends messages to it, finding it is still alive.	788	and then later sends messages to it, finding it is still alive.
679		789
680	=item * Erlang can send messages to the wrong port, AEMP does not.	790	=item * Erlang can send messages to the wrong port, AEMP does not.
681		791
682	In erlang it is quite possible that a node that restarts reuses a process	792	In Erlang it is quite possible that a node that restarts reuses a process
683	ID known to other nodes for a completely different process, causing	793	ID known to other nodes for a completely different process, causing
684	messages destined for that process to end up in an unrelated process.	794	messages destined for that process to end up in an unrelated process.
685		795
686	AEMP never reuses port IDs, so old messages or old port IDs floating	796	AEMP never reuses port IDs, so old messages or old port IDs floating
687	around in the network will not be sent to an unrelated port.	797	around in the network will not be sent to an unrelated port.
…		…
693	securely authenticate nodes.	803	securely authenticate nodes.
694		804
695	=item * The AEMP protocol is optimised for both text-based and binary	805	=item * The AEMP protocol is optimised for both text-based and binary
696	communications.	806	communications.
697		807
698	The AEMP protocol, unlike the erlang protocol, supports both	808	The AEMP protocol, unlike the Erlang protocol, supports both
699	language-independent text-only protocols (good for debugging) and binary,	809	language-independent text-only protocols (good for debugging) and binary,
700	language-specific serialisers (e.g. Storable).	810	language-specific serialisers (e.g. Storable).
701		811
702	It has also been carefully designed to be implementable in other languages	812	It has also been carefully designed to be implementable in other languages
703	with a minimum of work while gracefully degrading fucntionality to make the	813	with a minimum of work while gracefully degrading fucntionality to make the
704	protocol simple.	814	protocol simple.
705		815
		816	=item * AEMP has more flexible monitoring options than Erlang.
		817
		818	In Erlang, you can chose to receive I<all> exit signals as messages
		819	or I<none>, there is no in-between, so monitoring single processes is
		820	difficult to implement. Monitoring in AEMP is more flexible than in
		821	Erlang, as one can choose between automatic kill, exit message or callback
		822	on a per-process basis.
		823
		824	=item * Erlang tries to hide remote/local connections, AEMP does not.
		825
		826	Monitoring in Erlang is not an indicator of process death/crashes,
		827	as linking is (except linking is unreliable in Erlang).
		828
		829	In AEMP, you don't "look up" registered port names or send to named ports
		830	that might or might not be persistent. Instead, you normally spawn a port
		831	on the remote node. The init function monitors the you, and you monitor
		832	the remote port. Since both monitors are local to the node, they are much
		833	more reliable.
		834
		835	This also saves round-trips and avoids sending messages to the wrong port
		836	(hard to do in Erlang).
		837
706	=back	838	=back
707		839
708	=head1 SEE ALSO	840	=head1 SEE ALSO
709		841
710	L<AnyEvent>.	842	L<AnyEvent>.

Diff Legend

-–
+Removed lines
-+
+Added lines
-<
+Changed lines
->
+Changed lines

Comparing AnyEvent-MP/MP.pm (file contents): Revision 1.34 by root, Wed Aug 5 23:50:46 2009 UTC vs. Revision 1.39 by root, Fri Aug 7 23:21:48 2009 UTC

Diff Legend

Comparing AnyEvent-MP/MP.pm (file contents):
Revision 1.34 by root, Wed Aug 5 23:50:46 2009 UTC vs.
Revision 1.39 by root, Fri Aug 7 23:21:48 2009 UTC