AnyEvent-MP

 view release on metacpan or  search on metacpan

Changes  view on Meta::CPAN

        - handle unsupported remote framings more gracefully.

1.26 Wed Dec 30 16:48:37 CET 2009
	- INCOMPATIBLE CHANGE: the high-level node protocol changed,
          all nodes need to upgrade.
	- remote kil's did not work (reported by Eugene Grigoriev).
        - documented monitor_timeout, connect_interval, auth_offer,
          auth_accept, framing_format, autocork and nodelay options
          and make them configurable via bin/aemp.
        - some doc updates.
        - remote kil's were not synchronous to message sends which affected
          nobody, as remote kils were broken.
        - remote mon/unmonitor requests were not synchronous to message
          sends either sometimes, although it likely didnt matter.

1.24 Wed Dec  9 14:59:52 CET 2009
	- codename "the foul egg".
	- increased "unmonitored local port died" message level to 2, so
          it is displayed by default now.
        - generate random seed at configure time, not module loading time,
          so fork&configure works as expected.
        - decreased "seed"-related message priority in Global from 0 (d'oh)
          to 9, as they are not signifcant.

MP.pm  view on Meta::CPAN

   &snd;

   $port
}

=back

=head1 DISTRIBUTED DATABASE

AnyEvent::MP comes with a simple distributed database. The database will
be mirrored asynchronously on all global nodes. Other nodes bind to one
of the global nodes for their needs. Every node has a "local database"
which contains all the values that are set locally. All local databases
are merged together to form the global database, which can be queried.

The database structure is that of a two-level hash - the database hash
contains hashes which contain values, similarly to a perl hash of hashes,
i.e.:

  $DATABASE{$family}{$subkey} = $value

MP.pm  view on Meta::CPAN

no useful purpose. For the same reason the pattern-matching abilities
of AnyEvent::MP are more limited, as there is little need to be able to
filter messages without dequeuing them.

This is not a philosophical difference, but simply stems from AnyEvent::MP
being event-based, while Erlang is process-based.

You can have a look at L<Coro::MP> for a more Erlang-like process model on
top of AEMP and Coro threads.

=item * Erlang sends are synchronous, AEMP sends are asynchronous.

Sending messages in Erlang is synchronous and blocks the process until
a connection has been established and the message sent (and so does not
need a queue that can overflow). AEMP sends return immediately, connection
establishment is handled in the background.

=item * Erlang suffers from silent message loss, AEMP does not.

Erlang implements few guarantees on messages delivery - messages can get
lost without any of the processes realising it (i.e. you send messages a,
b, and c, and the other side only receives messages a and c).

MP/Kernel.pm  view on Meta::CPAN

}

sub port_is_local($) {
   my ($nodeid, undef) = split /#/, $_[0], 2;

   $nodeid eq $NODE
}

=item snd_to_func $node, $func, @args

Expects a node ID and a name of a function. Asynchronously tries to call
this function with the given arguments on that node.

This function can be used to implement C<spawn>-like interfaces.

=cut

sub snd_to_func($$;@) {
   my $nodeid = shift;

   # on $NODE, we artificially delay... (for spawn)

README  view on Meta::CPAN

        If no time-out is given (or it is "undef"), then the local port will
        monitor the remote port instead, so it eventually gets cleaned-up.

        Currently this function returns the temporary port, but this
        "feature" might go in future versions unless you can make a
        convincing case that this is indeed useful for something.

DISTRIBUTED DATABASE
    AnyEvent::MP comes with a simple distributed database. The database will
    be mirrored asynchronously on all global nodes. Other nodes bind to one
    of the global nodes for their needs. Every node has a "local database"
    which contains all the values that are set locally. All local databases
    are merged together to form the global database, which can be queried.

    The database structure is that of a two-level hash - the database hash
    contains hashes which contain values, similarly to a perl hash of
    hashes, i.e.:

      $DATABASE{$family}{$subkey} = $value

README  view on Meta::CPAN

        pattern-matching abilities of AnyEvent::MP are more limited, as
        there is little need to be able to filter messages without dequeuing
        them.

        This is not a philosophical difference, but simply stems from
        AnyEvent::MP being event-based, while Erlang is process-based.

        You can have a look at Coro::MP for a more Erlang-like process model
        on top of AEMP and Coro threads.

    *   Erlang sends are synchronous, AEMP sends are asynchronous.

        Sending messages in Erlang is synchronous and blocks the process
        until a connection has been established and the message sent (and so
        does not need a queue that can overflow). AEMP sends return
        immediately, connection establishment is handled in the background.

    *   Erlang suffers from silent message loss, AEMP does not.

        Erlang implements few guarantees on messages delivery - messages can
        get lost without any of the processes realising it (i.e. you send
        messages a, b, and c, and the other side only receives messages a
        and c).