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

Comparing AnyEvent-Fork-RPC/RPC.pm (file contents):
Revision 1.12 by root, Thu Apr 18 10:40:34 2013 UTC vs.
Revision 1.16 by root, Thu Apr 18 14:07:15 2013 UTC

       ->new
       ->require ("MyModule")
       ->AnyEvent::Fork::RPC::run (
          "MyModule::server",
       );
+   use AnyEvent;
    my $cv = AE::cv;
    $rpc->(1, 2, 3, sub {
       print "MyModule::server returned @_\n";
 The default server used in the child does all I/O blockingly, and only
 allows a single RPC call to execute concurrently.
 Setting C<async> to a true value switches to another implementation that
-uses L<AnyEvent> in the child and allows multiple concurrent RPC calls.
+uses L<AnyEvent> in the child and allows multiple concurrent RPC calls (it
+does not support recursion in the event loop however, blocking condvar
+calls will fail).
 The actual API in the child is documented in the section that describes
 the calling semantics of the returned C<$rpc> function.
 If you want to pre-load the actual back-end modules to enable memory
 synchronous, and C<AnyEvent::Fork::RPC::Async> for asynchronous mode.
 If you use a template process and want to fork both sync and async
 children, then it is permissible to load both modules.
-=item serialiser => $string (default: '(sub { pack "(w/a*)*", @_ }, sub { unpack "(w/a*)*", shift })')
+=item serialiser => $string (default: $AnyEvent::Fork::RPC::STRING_SERIALISER)
 All arguments, result data and event data have to be serialised to be
 transferred between the processes. For this, they have to be frozen and
 thawed in both parent and child processes.
 By default, only octet strings can be passed between the processes, which
-is reasonably fast and efficient.
+is reasonably fast and efficient and requires no extra modules.
 For more complicated use cases, you can provide your own freeze and thaw
 functions, by specifying a string with perl source code. It's supposed to
 return two code references when evaluated: the first receives a list of
 perl values and must return an octet string. The second receives the octet
 If you need an external module for serialisation, then you can either
 pre-load it into your L<AnyEvent::Fork> process, or you can add a C<use>
 or C<require> statement into the serialiser string. Or both.
+Here are some examples - some of them are also available as global
+variables that make them easier to use.
+=over 4
+=item octet strings - C<$AnyEvent::Fork::RPC::STRING_SERIALISER>
+This serialiser concatenates length-prefixes octet strings, and is the
+default.
+Implementation:
+   (
+      sub { pack   "(w/a*)*", @_ },
+      sub { unpack "(w/a*)*", shift }
+   )
+=item json - C<$AnyEvent::Fork::RPC::JSON_SERIALISER>
+This serialiser creates JSON arrays - you have to make sure the L<JSON>
+module is installed for this serialiser to work. It can be beneficial for
+sharing when you preload the L<JSON> module in a template process.
+L<JSON> (with L<JSON::XS> installed) is slower than the octet string
+serialiser, but usually much faster than L<Storable>, unless big chunks of
+binary data need to be transferred.
+Implementation:
+   use JSON ();
+   (
+      sub {    JSON::encode_json \@_ },
+      sub { @{ JSON::decode_json shift } }
+   )
+=item storable - C<$AnyEvent::Fork::RPC::STORABLE_SERIALISER>
+This serialiser uses L<Storable>, which means it has high chance of
+serialising just about anything you throw at it, at the cost of having
+very high overhead per operation. It also comes with perl.
+Implementation:
+   use Storable ();
+   (
+      sub {    Storable::freeze \@_ },
+      sub { @{ Storable::thaw shift } }
+   )
+=back
 =back
 See the examples section earlier in this document for some actual
 examples.
 =cut
-our $STRING_SERIALISER = '(sub { pack "(w/a*)*", @_ }, sub { unpack "(w/a*)*", shift })';
+our $STRING_SERIALISER   = '(sub { pack "(w/a*)*", @_ }, sub { unpack "(w/a*)*", shift })';
+our $JSON_SERIALISER     = 'use JSON (); (sub { JSON::encode_json \@_ }, sub { @{ JSON::decode_json shift } })';
+our $STORABLE_SERIALISER = 'use Storable (); (sub { Storable::freeze \@_ }, sub { @{ Storable::thaw shift } })';
 sub run {
    my ($self, $function, %arg) = @_;
    my $serialiser = delete $arg{serialiser} || $STRING_SERIALISER;
             }
          } elsif (defined $len) {
             undef $rw; undef $ww; # it ends here
             if (@rcb || %rcb) {
-               use Data::Dump;ddx[\@rcb,\%rcb];#d#
                $on_error->("unexpected eof");
             } else {
                $on_destroy->();
             }
          } elsif ($! != Errno::EAGAIN && $! != Errno::EWOULDBLOCK) {
 are queued and the jobs are slow, they will all run concurrently. The
 child must implement some queueing/limiting mechanism if this causes
 problems. Alternatively, the parent could limit the amount of rpc calls
 that are outstanding.
+Blocking use of condvars is not supported.
 Using event-based modules such as L<IO::AIO>, L<Gtk2>, L<Tk> and so on is
 easy.
 =back
 so you might want to look into L<AnyEvent::FDpasser> which can handle the
 gory details.
 =head1 SEE ALSO
-L<AnyEvent::Fork> (to create the processes in the first place),
+L<AnyEvent::Fork>, to create the processes in the first place.
-L<AnyEvent::Fork::Pool> (to manage whole pools of processes).
+L<AnyEvent::Fork::Pool>, to manage whole pools of processes.
 =head1 AUTHOR AND CONTACT INFORMATION
  Marc Lehmann <schmorp@schmorp.de>
  http://software.schmorp.de/pkg/AnyEvent-Fork-RPC

Diff Legend

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

Comparing AnyEvent-Fork-RPC/RPC.pm (file contents): Revision 1.12 by root, Thu Apr 18 10:40:34 2013 UTC vs. Revision 1.16 by root, Thu Apr 18 14:07:15 2013 UTC

Diff Legend

Comparing AnyEvent-Fork-RPC/RPC.pm (file contents):
Revision 1.12 by root, Thu Apr 18 10:40:34 2013 UTC vs.
Revision 1.16 by root, Thu Apr 18 14:07:15 2013 UTC