AnyEvent-MP

 view release on metacpan or  search on metacpan

MP.pm  view on Meta::CPAN

=head1 NAME

AnyEvent::MP - erlang-style multi-processing/message-passing framework

=head1 SYNOPSIS

   use AnyEvent::MP;

   $NODE      # contains this node's node ID
   NODE       # returns this node's node ID

   $SELF      # receiving/own port id in rcv callbacks

MP.pm  view on Meta::CPAN

   # distributed database - queries
   db_family $family => $cb->(\%familyhash)
   db_keys   $family => $cb->(\@keys)
   db_values $family => $cb->(\@values)

   # distributed database - monitoring a family
   db_mon $family => $cb->(\%familyhash, \@added, \@changed, \@deleted)

=head1 DESCRIPTION

This module (-family) implements a simple message passing framework.

Despite its simplicity, you can securely message other processes running
on the same or other hosts, and you can supervise entities remotely.

For an introduction to this module family, see the L<AnyEvent::MP::Intro>
manual page and the examples under F<eg/>.

=head1 CONCEPTS

=over 4

MP.pm  view on Meta::CPAN

=back

=head1 AnyEvent::MP vs. Distributed Erlang

AnyEvent::MP got lots of its ideas from distributed Erlang (Erlang node
== aemp node, Erlang process == aemp port), so many of the documents and
programming techniques employed by Erlang apply to AnyEvent::MP. Here is a
sample:

   http://www.erlang.se/doc/programming_rules.shtml
   http://erlang.org/doc/getting_started/part_frame.html # chapters 3 and 4
   http://erlang.org/download/erlang-book-part1.pdf      # chapters 5 and 6
   http://erlang.org/download/armstrong_thesis_2003.pdf  # chapters 4 and 5

Despite the similarities, there are also some important differences:

=over 4

=item * Node IDs are arbitrary strings in AEMP.

Erlang relies on special naming and DNS to work everywhere in the same

MP.pm  view on Meta::CPAN

There are vague plans to implement some form of routing domains, which
might or might not bring back listener-less nodes, but don't count on it.

The fact that most connections are now optional somewhat mitigates this,
as a node can be effectively unreachable from the outside without any
problems, as long as it isn't a global node and only reaches out to other
nodes (as opposed to being contacted from other nodes).

=item $AnyEvent::MP::Kernel::WARN has gone.

AnyEvent has acquired a logging framework (L<AnyEvent::Log>), and AEMP now
uses this, and so should your programs.

Every module now documents what kinds of messages it generates, with
AnyEvent::MP acting as a catch all.

On the positive side, this means that instead of setting
C<PERL_ANYEVENT_MP_WARNLEVEL>, you can get away by setting C<AE_VERBOSE> -
much less to type.

=back

README  view on Meta::CPAN

NAME
    AnyEvent::MP - erlang-style multi-processing/message-passing framework

SYNOPSIS
       use AnyEvent::MP;

       $NODE      # contains this node's node ID
       NODE       # returns this node's node ID

       $SELF      # receiving/own port id in rcv callbacks

       # initialise the node so it can send/receive messages

README  view on Meta::CPAN

       # distributed database - queries
       db_family $family => $cb->(\%familyhash)
       db_keys   $family => $cb->(\@keys)
       db_values $family => $cb->(\@values)

       # distributed database - monitoring a family
       db_mon $family => $cb->(\%familyhash, \@added, \@changed, \@deleted)

DESCRIPTION
    This module (-family) implements a simple message passing framework.

    Despite its simplicity, you can securely message other processes running
    on the same or other hosts, and you can supervise entities remotely.

    For an introduction to this module family, see the AnyEvent::MP::Intro
    manual page and the examples under eg/.

CONCEPTS
    port
        Not to be confused with a TCP port, a "port" is something you can

README  view on Meta::CPAN

              print "-$_=$family->{$_}\n" for @$d;
           };

AnyEvent::MP vs. Distributed Erlang
    AnyEvent::MP got lots of its ideas from distributed Erlang (Erlang node
    == aemp node, Erlang process == aemp port), so many of the documents and
    programming techniques employed by Erlang apply to AnyEvent::MP. Here is
    a sample:

       http://www.erlang.se/doc/programming_rules.shtml
       http://erlang.org/doc/getting_started/part_frame.html # chapters 3 and 4
       http://erlang.org/download/erlang-book-part1.pdf      # chapters 5 and 6
       http://erlang.org/download/armstrong_thesis_2003.pdf  # chapters 4 and 5

    Despite the similarities, there are also some important differences:

    *   Node IDs are arbitrary strings in AEMP.

        Erlang relies on special naming and DNS to work everywhere in the
        same way. AEMP relies on each node somehow knowing its own
        address(es) (e.g. by configuration or DNS), and possibly the

README  view on Meta::CPAN

        which might or might not bring back listener-less nodes, but don't
        count on it.

        The fact that most connections are now optional somewhat mitigates
        this, as a node can be effectively unreachable from the outside
        without any problems, as long as it isn't a global node and only
        reaches out to other nodes (as opposed to being contacted from other
        nodes).

    $AnyEvent::MP::Kernel::WARN has gone.
        AnyEvent has acquired a logging framework (AnyEvent::Log), and AEMP
        now uses this, and so should your programs.

        Every module now documents what kinds of messages it generates, with
        AnyEvent::MP acting as a catch all.

        On the positive side, this means that instead of setting
        "PERL_ANYEVENT_MP_WARNLEVEL", you can get away by setting
        "AE_VERBOSE" - much less to type.

LOGGING