ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/AnyEvent-Fork-RPC/RPC.pm
(Generate patch)

Comparing AnyEvent-Fork-RPC/RPC.pm (file contents):
Revision 1.29 by root, Sun Aug 25 21:52:15 2013 UTC vs.
Revision 1.39 by root, Thu May 12 16:54:43 2016 UTC

… …
175you really I<are> done. 175you really I<are> done.
176 176
177=head2 Example 2: Asynchronous Backend 177=head2 Example 2: Asynchronous Backend
178 178
179This example implements multiple count-downs in the child, using 179This example implements multiple count-downs in the child, using
180L<AnyEvent> timers. While this is a bit silly (one could use timers in te 180L<AnyEvent> timers. While this is a bit silly (one could use timers in the
181parent just as well), it illustrates the ability to use AnyEvent in the 181parent just as well), it illustrates the ability to use AnyEvent in the
182child and the fact that responses can arrive in a different order then the 182child and the fact that responses can arrive in a different order then the
183requests. 183requests.
184 184
185It also shows how to embed the actual child code into a C<__DATA__> 185It also shows how to embed the actual child code into a C<__DATA__>
… …
336 $rpc->(add => 1, 3, Coro::rouse_cb); say Coro::rouse_wait; 336 $rpc->(add => 1, 3, Coro::rouse_cb); say Coro::rouse_wait;
337 $rpc->(mul => 3, 2, Coro::rouse_cb); say Coro::rouse_wait; 337 $rpc->(mul => 3, 2, Coro::rouse_cb); say Coro::rouse_wait;
338 338
339The C<say>'s will print C<4> and C<6>. 339The C<say>'s will print C<4> and C<6>.
340 340
341=head2 Example 4: Forward AnyEvent::Log messages using C<on_event>
342
343This partial example shows how to use the C<event> function to forward
344L<AnyEvent::Log> messages to the parent.
345
346For this, the parent needs to provide a suitable C<on_event>:
347
348 ->AnyEvent::Fork::RPC::run (
349 on_event => sub {
350 if ($_[0] eq "ae_log") {
351 my (undef, $level, $message) = @_;
352 AE::log $level, $message;
353 } else {
354 # other event types
355 }
356 },
357 )
358
359In the child, as early as possible, the following code should reconfigure
360L<AnyEvent::Log> to log via C<AnyEvent::Fork::RPC::event>:
361
362 $AnyEvent::Log::LOG->log_cb (sub {
363 my ($timestamp, $orig_ctx, $level, $message) = @{+shift};
364
365 if (defined &AnyEvent::Fork::RPC::event) {
366 AnyEvent::Fork::RPC::event (ae_log => $level, $message);
367 } else {
368 warn "[$$ before init] $message\n";
369 }
370 });
371
372There is an important twist - the C<AnyEvent::Fork::RPC::event> function
373is only defined when the child is fully initialised. If you redirect the
374log messages in your C<init> function for example, then the C<event>
375function might not yet be available. This is why the log callback checks
376whether the fucntion is there using C<defined>, and only then uses it to
377log the message.
378
341=head1 PARENT PROCESS USAGE 379=head1 PARENT PROCESS USAGE
342 380
343This module exports nothing, and only implements a single function: 381This module exports nothing, and only implements a single function:
344 382
345=over 4 383=over 4
… …
353use Errno (); 391use Errno ();
354use Guard (); 392use Guard ();
355 393
356use AnyEvent; 394use AnyEvent;
357 395
358our $VERSION = 1.1; 396our $VERSION = 1.22;
359 397
360=item my $rpc = AnyEvent::Fork::RPC::run $fork, $function, [key => value...] 398=item my $rpc = AnyEvent::Fork::RPC::run $fork, $function, [key => value...]
361 399
362The traditional way to call it. But it is way cooler to call it in the 400The traditional way to call it. But it is way cooler to call it in the
363following way: 401following way:
… …
416It is called very early - before the serialisers are created or the 454It is called very early - before the serialisers are created or the
417C<$function> name is resolved into a function reference, so it could be 455C<$function> name is resolved into a function reference, so it could be
418used to load any modules that provide the serialiser or function. It can 456used to load any modules that provide the serialiser or function. It can
419not, however, create events. 457not, however, create events.
420 458
459=item done => $function (default C<CORE::exit>)
460
461The function to call when the asynchronous backend detects an end of file
462condition when reading from the communications socket I<and> there are no
463outstanding requests. It's ignored by the synchronous backend.
464
465By overriding this you can prolong the life of a RPC process after e.g.
466the parent has exited by running the event loop in the provided function
467(or simply calling it, for example, when your child process uses L<EV> you
468could provide L<EV::run> as C<done> function).
469
470Of course, in that case you are responsible for exiting at the appropriate
471time and not returning from
472
421=item async => $boolean (default: 0) 473=item async => $boolean (default: 0)
422 474
423The default server used in the child does all I/O blockingly, and only 475The default server used in the child does all I/O blockingly, and only
424allows a single RPC call to execute concurrently. 476allows a single RPC call to execute concurrently.
425 477
… …
442 494
443All arguments, result data and event data have to be serialised to be 495All arguments, result data and event data have to be serialised to be
444transferred between the processes. For this, they have to be frozen and 496transferred between the processes. For this, they have to be frozen and
445thawed in both parent and child processes. 497thawed in both parent and child processes.
446 498
447By default, only octet strings can be passed between the processes, which 499By default, only octet strings can be passed between the processes,
448is reasonably fast and efficient and requires no extra modules. 500which is reasonably fast and efficient and requires no extra modules
501(the C<AnyEvent::Fork::RPC> distribution does not provide these extra
502serialiser modules).
449 503
450For more complicated use cases, you can provide your own freeze and thaw 504For more complicated use cases, you can provide your own freeze and thaw
451functions, by specifying a string with perl source code. It's supposed to 505functions, by specifying a string with perl source code. It's supposed to
452return two code references when evaluated: the first receives a list of 506return two code references when evaluated: the first receives a list of
453perl values and must return an octet string. The second receives the octet 507perl values and must return an octet string. The second receives the octet
… …
455 509
456If you need an external module for serialisation, then you can either 510If you need an external module for serialisation, then you can either
457pre-load it into your L<AnyEvent::Fork> process, or you can add a C<use> 511pre-load it into your L<AnyEvent::Fork> process, or you can add a C<use>
458or C<require> statement into the serialiser string. Or both. 512or C<require> statement into the serialiser string. Or both.
459 513
460Here are some examples - some of them are also available as global 514Here are some examples - all of them are also available as global
461variables that make them easier to use. 515variables that make them easier to use.
462 516
463=over 4 517=over 4
464 518
465=item octet strings - C<$AnyEvent::Fork::RPC::STRING_SERIALISER> 519=item C<$AnyEvent::Fork::RPC::STRING_SERIALISER> - octet strings only
466 520
467This serialiser concatenates length-prefixes octet strings, and is the 521This serialiser (currently the default) concatenates length-prefixes octet
468default. That means you can only pass (and return) strings containing 522strings, and is the default. That means you can only pass (and return)
469character codes 0-255. 523strings containing character codes 0-255.
524
525The main advantages of this serialiser are the high speed and that it
526doesn't need another module. The main disadvantage is that you are very
527limited in what you can pass - only octet strings.
470 528
471Implementation: 529Implementation:
472 530
473 ( 531 (
474 sub { pack "(w/a*)*", @_ }, 532 sub { pack "(w/a*)*", @_ },
475 sub { unpack "(w/a*)*", shift } 533 sub { unpack "(w/a*)*", shift }
476 ) 534 )
477 535
478=item json - C<$AnyEvent::Fork::RPC::JSON_SERIALISER> 536=item C<$AnyEvent::Fork::RPC::CBOR_XS_SERIALISER> - uses L<CBOR::XS>
537
538This serialiser creates CBOR::XS arrays - you have to make sure the
539L<CBOR::XS> module is installed for this serialiser to work. It can be
540beneficial for sharing when you preload the L<CBOR::XS> module in a template
541process.
542
543L<CBOR::XS> is about as fast as the octet string serialiser, but supports
544complex data structures (similar to JSON) and is faster than any of the
545other serialisers. If you have the L<CBOR::XS> module available, it's the
546best choice.
547
548The encoder enables C<allow_sharing> (so this serialisation method can
549encode cyclic and self-referencing data structures).
550
551Implementation:
552
553 use CBOR::XS ();
554 (
555 sub { CBOR::XS::encode_cbor_sharing \@_ },
556 sub { @{ CBOR::XS::decode_cbor shift } }
557 )
558
559=item C<$AnyEvent::Fork::RPC::JSON_SERIALISER> - uses L<JSON::XS> or L<JSON>
479 560
480This serialiser creates JSON arrays - you have to make sure the L<JSON> 561This serialiser creates JSON arrays - you have to make sure the L<JSON>
481module is installed for this serialiser to work. It can be beneficial for 562module is installed for this serialiser to work. It can be beneficial for
482sharing when you preload the L<JSON> module in a template process. 563sharing when you preload the L<JSON> module in a template process.
483 564
… …
491 ( 572 (
492 sub { JSON::encode_json \@_ }, 573 sub { JSON::encode_json \@_ },
493 sub { @{ JSON::decode_json shift } } 574 sub { @{ JSON::decode_json shift } }
494 ) 575 )
495 576
496=item storable - C<$AnyEvent::Fork::RPC::STORABLE_SERIALISER> 577=item C<$AnyEvent::Fork::RPC::STORABLE_SERIALISER> - L<Storable>
497 578
498This serialiser uses L<Storable>, which means it has high chance of 579This serialiser uses L<Storable>, which means it has high chance of
499serialising just about anything you throw at it, at the cost of having 580serialising just about anything you throw at it, at the cost of having
500very high overhead per operation. It also comes with perl. It should be 581very high overhead per operation. It also comes with perl. It should be
501used when you need to serialise complex data structures. 582used when you need to serialise complex data structures.
… …
506 ( 587 (
507 sub { Storable::freeze \@_ }, 588 sub { Storable::freeze \@_ },
508 sub { @{ Storable::thaw shift } } 589 sub { @{ Storable::thaw shift } }
509 ) 590 )
510 591
511=item portable storable - C<$AnyEvent::Fork::RPC::NSTORABLE_SERIALISER> 592=item C<$AnyEvent::Fork::RPC::NSTORABLE_SERIALISER> - portable Storable
512 593
513This serialiser also uses L<Storable>, but uses it's "network" format 594This serialiser also uses L<Storable>, but uses it's "network" format
514to serialise data, which makes it possible to talk to different 595to serialise data, which makes it possible to talk to different
515perl binaries (for example, when talking to a process created with 596perl binaries (for example, when talking to a process created with
516L<AnyEvent::Fork::Remote>). 597L<AnyEvent::Fork::Remote>).
… …
531examples. 612examples.
532 613
533=cut 614=cut
534 615
535our $STRING_SERIALISER = '(sub { pack "(w/a*)*", @_ }, sub { unpack "(w/a*)*", shift })'; 616our $STRING_SERIALISER = '(sub { pack "(w/a*)*", @_ }, sub { unpack "(w/a*)*", shift })';
617our $CBOR_XS_SERIALISER = 'use CBOR::XS (); (sub { CBOR::XS::encode_cbor_sharing \@_ }, sub { @{ CBOR::XS::decode_cbor shift } })';
536our $JSON_SERIALISER = 'use JSON (); (sub { JSON::encode_json \@_ }, sub { @{ JSON::decode_json shift } })'; 618our $JSON_SERIALISER = 'use JSON (); (sub { JSON::encode_json \@_ }, sub { @{ JSON::decode_json shift } })';
537our $STORABLE_SERIALISER = 'use Storable (); (sub { Storable::freeze \@_ }, sub { @{ Storable::thaw shift } })'; 619our $STORABLE_SERIALISER = 'use Storable (); (sub { Storable::freeze \@_ }, sub { @{ Storable::thaw shift } })';
538our $NSTORABLE_SERIALISER = 'use Storable (); (sub { Storable::nfreeze \@_ }, sub { @{ Storable::thaw shift } })'; 620our $NSTORABLE_SERIALISER = 'use Storable (); (sub { Storable::nfreeze \@_ }, sub { @{ Storable::thaw shift } })';
539 621
540sub run { 622sub run {
541 my ($self, $function, %arg) = @_; 623 my ($self, $function, %arg) = @_;
… …
577 }; 659 };
578 660
579 my $module = "AnyEvent::Fork::RPC::" . ($arg{async} ? "Async" : "Sync"); 661 my $module = "AnyEvent::Fork::RPC::" . ($arg{async} ? "Async" : "Sync");
580 662
581 $self->require ($module) 663 $self->require ($module)
582 ->send_arg ($function, $arg{init}, $serialiser) 664 ->send_arg ($function, $arg{init}, $serialiser, $arg{done} || "$module\::do_exit")
583 ->run ("$module\::run", sub { 665 ->run ("$module\::run", sub {
584 $fh = shift; 666 $fh = shift;
585 667
586 my ($id, $len); 668 my ($id, $len);
587 $rw = AE::io $fh, 0, sub { 669 $rw = AE::io $fh, 0, sub {
… …
703See the examples section earlier in this document for some actual 785See the examples section earlier in this document for some actual
704examples. 786examples.
705 787
706=back 788=back
707 789
790=head2 PROCESS EXIT
791
792If and when the child process exits depends on the backend and
793configuration. Apart from explicit exits (e.g. by calling C<exit>) or
794runtime conditions (uncaught exceptions, signals etc.), the backends exit
795under these conditions:
796
797=over 4
798
799=item Synchronous Backend
800
801The synchronous backend is very simple: when the process waits for another
802request to arrive and the writing side (usually in the parent) is closed,
803it will exit normally, i.e. as if your main program reached the end of the
804file.
805
806That means that if your parent process exits, the RPC process will usually
807exit as well, either because it is idle anyway, or because it executes a
808request. In the latter case, you will likely get an error when the RPc
809process tries to send the results to the parent (because agruably, you
810shouldn't exit your parent while there are still outstanding requests).
811
812The process is usually quiescent when it happens, so it should rarely be a
813problem, and C<END> handlers can be used to clean up.
814
815=item Asynchronous Backend
816
817For the asynchronous backend, things are more complicated: Whenever it
818listens for another request by the parent, it might detect that the socket
819was closed (e.g. because the parent exited). It will sotp listening for
820new requests and instead try to write out any remaining data (if any) or
821simply check whether the socket can be written to. After this, the RPC
822process is effectively done - no new requests are incoming, no outstanding
823request data can be written back.
824
825Since chances are high that there are event watchers that the RPC server
826knows nothing about (why else would one use the async backend if not for
827the ability to register watchers?), the event loop would often happily
828continue.
829
830This is why the asynchronous backend explicitly calls C<CORE::exit> when
831it is done (under other circumstances, such as when there is an I/O error
832and there is outstanding data to write, it will log a fatal message via
833L<AnyEvent::Log>, also causing the program to exit).
834
835You can override this by specifying a function name to call via the C<done>
836parameter instead.
837
838=back
839
708=head1 ADVANCED TOPICS 840=head1 ADVANCED TOPICS
709 841
710=head2 Choosing a backend 842=head2 Choosing a backend
711 843
712So how do you decide which backend to use? Well, that's your problem to 844So how do you decide which backend to use? Well, that's your problem to
… …
765are queued and the jobs are slow, they will all run concurrently. The 897are queued and the jobs are slow, they will all run concurrently. The
766child must implement some queueing/limiting mechanism if this causes 898child must implement some queueing/limiting mechanism if this causes
767problems. Alternatively, the parent could limit the amount of rpc calls 899problems. Alternatively, the parent could limit the amount of rpc calls
768that are outstanding. 900that are outstanding.
769 901
770Blocking use of condvars is not supported. 902Blocking use of condvars is not supported (in the main thread, outside of
903e.g. L<Coro> threads).
771 904
772Using event-based modules such as L<IO::AIO>, L<Gtk2>, L<Tk> and so on is 905Using event-based modules such as L<IO::AIO>, L<Gtk2>, L<Tk> and so on is
773easy. 906easy.
774 907
775=back 908=back
… …
841gory details. 974gory details.
842 975
843=head1 EXCEPTIONS 976=head1 EXCEPTIONS
844 977
845There are no provisions whatsoever for catching exceptions at this time - 978There are no provisions whatsoever for catching exceptions at this time -
846in the child, exeptions might kill the process, causing calls to be lost 979in the child, exceptions might kill the process, causing calls to be lost
847and the parent encountering a fatal error. In the parent, exceptions in 980and the parent encountering a fatal error. In the parent, exceptions in
848the result callback will not be caught and cause undefined behaviour. 981the result callback will not be caught and cause undefined behaviour.
849 982
850=head1 SEE ALSO 983=head1 SEE ALSO
851 984

Diff Legend

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