| … | |
… | |
| 22 | snd $port2, ping => $port1; |
22 | snd $port2, ping => $port1; |
| 23 | |
23 | |
| 24 | # more, smarter, matches (_any_ is exported by this module) |
24 | # more, smarter, matches (_any_ is exported by this module) |
| 25 | rcv $port, [child_died => $pid] => sub { ... |
25 | rcv $port, [child_died => $pid] => sub { ... |
| 26 | rcv $port, [_any_, _any_, 3] => sub { .. $_[2] is 3 |
26 | rcv $port, [_any_, _any_, 3] => sub { .. $_[2] is 3 |
| 27 | |
|
|
| 28 | # linking two ports, so they both crash together |
|
|
| 29 | lnk $port1, $port2; |
|
|
| 30 | |
27 | |
| 31 | # monitoring |
28 | # monitoring |
| 32 | mon $port, $cb->(@msg) # callback is invoked on death |
29 | mon $port, $cb->(@msg) # callback is invoked on death |
| 33 | mon $port, $otherport # kill otherport on abnormal death |
30 | mon $port, $otherport # kill otherport on abnormal death |
| 34 | mon $port, $otherport, @msg # send message on death |
31 | mon $port, $otherport, @msg # send message on death |
| … | |
… | |
| 513 | C<$rvport> defaults to C<$SELF>. |
510 | C<$rvport> defaults to C<$SELF>. |
| 514 | |
511 | |
| 515 | In the last form (message), a message of the form C<@msg, @reason> will be |
512 | In the last form (message), a message of the form C<@msg, @reason> will be |
| 516 | C<snd>. |
513 | C<snd>. |
| 517 | |
514 | |
|
|
515 | As a rule of thumb, monitoring requests should always monitor a port from |
|
|
516 | a local port (or callback). The reason is that kill messages might get |
|
|
517 | lost, just like any other message. Another less obvious reason is that |
|
|
518 | even monitoring requests can get lost (for exmaple, when the connection |
|
|
519 | to the other node goes down permanently). When monitoring a port locally |
|
|
520 | these problems do not exist. |
|
|
521 | |
| 518 | Example: call a given callback when C<$port> is killed. |
522 | Example: call a given callback when C<$port> is killed. |
| 519 | |
523 | |
| 520 | mon $port, sub { warn "port died because of <@_>\n" }; |
524 | mon $port, sub { warn "port died because of <@_>\n" }; |
| 521 | |
525 | |
| 522 | Example: kill ourselves when C<$port> is killed abnormally. |
526 | Example: kill ourselves when C<$port> is killed abnormally. |
| … | |
… | |
| 578 | #TODO: mon-less form? |
582 | #TODO: mon-less form? |
| 579 | |
583 | |
| 580 | mon $port, sub { 0 && @refs } |
584 | mon $port, sub { 0 && @refs } |
| 581 | } |
585 | } |
| 582 | |
586 | |
| 583 | =item lnk $port1, $port2 |
|
|
| 584 | |
|
|
| 585 | =item lnk $otherport |
|
|
| 586 | |
|
|
| 587 | Link two ports. This is simply a shorthand for: |
|
|
| 588 | |
|
|
| 589 | mon $port1, $port2; |
|
|
| 590 | mon $port2, $port1; |
|
|
| 591 | |
|
|
| 592 | It means that if either one is killed abnormally, the other one gets |
|
|
| 593 | killed as well. |
|
|
| 594 | |
|
|
| 595 | The one-argument form assumes that one port is C<$SELF>. |
|
|
| 596 | |
|
|
| 597 | =cut |
|
|
| 598 | |
|
|
| 599 | sub lnk { |
|
|
| 600 | my $port1 = shift; |
|
|
| 601 | my $port2 = @_ ? shift : $SELF || Carp::croak 'lnk: called with one argument only, but $SELF not set,'; |
|
|
| 602 | |
|
|
| 603 | mon $port1, $port2; |
|
|
| 604 | mon $port2, $port1; |
|
|
| 605 | } |
|
|
| 606 | |
|
|
| 607 | =item kil $port[, @reason] |
587 | =item kil $port[, @reason] |
| 608 | |
588 | |
| 609 | Kill the specified port with the given C<@reason>. |
589 | Kill the specified port with the given C<@reason>. |
| 610 | |
590 | |
| 611 | If no C<@reason> is specified, then the port is killed "normally" (linked |
591 | If no C<@reason> is specified, then the port is killed "normally" (linked |
| … | |
… | |
| 759 | or I<none>, there is no in-between, so monitoring single processes is |
739 | or I<none>, there is no in-between, so monitoring single processes is |
| 760 | difficult to implement. Monitoring in AEMP is more flexible than in |
740 | difficult to implement. Monitoring in AEMP is more flexible than in |
| 761 | Erlang, as one can choose between automatic kill, exit message or callback |
741 | Erlang, as one can choose between automatic kill, exit message or callback |
| 762 | on a per-process basis. |
742 | on a per-process basis. |
| 763 | |
743 | |
| 764 | =item * Erlang has different semantics for monitoring and linking, AEMP has the same. |
744 | =item * Erlang tries to hide remote/local connections, AEMP does not. |
| 765 | |
745 | |
| 766 | Monitoring in Erlang is not an indicator of process death/crashes, |
746 | Monitoring in Erlang is not an indicator of process death/crashes, |
| 767 | as linking is (except linking is unreliable in Erlang). In AEMP, the |
747 | as linking is (except linking is unreliable in Erlang). |
| 768 | semantics of monitoring and linking are identical, linking is simply |
748 | |
| 769 | two-way monitoring with automatic kill. |
749 | In AEMP, you don't "look up" registered port names or send to named ports |
|
|
750 | that might or might not be persistent. Instead, you normally spawn a port |
|
|
751 | on the remote node. The init function monitors the you, and you monitor |
|
|
752 | the remote port. Since both monitors are local to the node, they are much |
|
|
753 | more reliable. |
|
|
754 | |
|
|
755 | This also saves round-trips and avoids sending messages to the wrong port |
|
|
756 | (hard to do in Erlang). |
| 770 | |
757 | |
| 771 | =back |
758 | =back |
| 772 | |
759 | |
| 773 | =head1 SEE ALSO |
760 | =head1 SEE ALSO |
| 774 | |
761 | |
