… | |
… | |
175 | you really I<are> done. |
175 | you really I<are> done. |
176 | |
176 | |
177 | =head2 Example 2: Asynchronous Backend |
177 | =head2 Example 2: Asynchronous Backend |
178 | |
178 | |
179 | This example implements multiple count-downs in the child, using |
179 | This example implements multiple count-downs in the child, using |
180 | L<AnyEvent> timers. While this is a bit silly (one could use timers in te |
180 | L<AnyEvent> timers. While this is a bit silly (one could use timers in the |
181 | parent just as well), it illustrates the ability to use AnyEvent in the |
181 | parent just as well), it illustrates the ability to use AnyEvent in the |
182 | child and the fact that responses can arrive in a different order then the |
182 | child and the fact that responses can arrive in a different order then the |
183 | requests. |
183 | requests. |
184 | |
184 | |
185 | It also shows how to embed the actual child code into a C<__DATA__> |
185 | It also shows how to embed the actual child code into a C<__DATA__> |
… | |
… | |
391 | use Errno (); |
391 | use Errno (); |
392 | use Guard (); |
392 | use Guard (); |
393 | |
393 | |
394 | use AnyEvent; |
394 | use AnyEvent; |
395 | |
395 | |
396 | our $VERSION = 1.1; |
396 | our $VERSION = 1.21; |
397 | |
397 | |
398 | =item my $rpc = AnyEvent::Fork::RPC::run $fork, $function, [key => value...] |
398 | =item my $rpc = AnyEvent::Fork::RPC::run $fork, $function, [key => value...] |
399 | |
399 | |
400 | The traditional way to call it. But it is way cooler to call it in the |
400 | The traditional way to call it. But it is way cooler to call it in the |
401 | following way: |
401 | following way: |
… | |
… | |
629 | }; |
629 | }; |
630 | |
630 | |
631 | my $module = "AnyEvent::Fork::RPC::" . ($arg{async} ? "Async" : "Sync"); |
631 | my $module = "AnyEvent::Fork::RPC::" . ($arg{async} ? "Async" : "Sync"); |
632 | |
632 | |
633 | $self->require ($module) |
633 | $self->require ($module) |
634 | ->send_arg ($function, $arg{init}, $serialiser, $arg{done} || "CORE::exit") |
634 | ->send_arg ($function, $arg{init}, $serialiser, $arg{done} || "$module\::do_exit") |
635 | ->run ("$module\::run", sub { |
635 | ->run ("$module\::run", sub { |
636 | $fh = shift; |
636 | $fh = shift; |
637 | |
637 | |
638 | my ($id, $len); |
638 | my ($id, $len); |
639 | $rw = AE::io $fh, 0, sub { |
639 | $rw = AE::io $fh, 0, sub { |
… | |
… | |
786 | |
786 | |
787 | For the asynchronous backend, things are more complicated: Whenever it |
787 | For the asynchronous backend, things are more complicated: Whenever it |
788 | listens for another request by the parent, it might detect that the socket |
788 | listens for another request by the parent, it might detect that the socket |
789 | was closed (e.g. because the parent exited). It will sotp listening for |
789 | was closed (e.g. because the parent exited). It will sotp listening for |
790 | new requests and instead try to write out any remaining data (if any) or |
790 | new requests and instead try to write out any remaining data (if any) or |
791 | simply check whether the socket cna be written to. After this, the RPC |
791 | simply check whether the socket can be written to. After this, the RPC |
792 | process is effectively done - no new requests are incoming, no outstanding |
792 | process is effectively done - no new requests are incoming, no outstanding |
793 | request data can be written back. |
793 | request data can be written back. |
794 | |
794 | |
795 | Since chances are high that there are event watchers that the RPC server |
795 | Since chances are high that there are event watchers that the RPC server |
796 | knows nothing about (why else would one use the async backend if not for |
796 | knows nothing about (why else would one use the async backend if not for |
797 | the ability to register watchers?), the event loop would often happily |
797 | the ability to register watchers?), the event loop would often happily |
798 | continue. |
798 | continue. |
799 | |
799 | |
800 | This is why the asynchronous backend explicitly calls C<CORE::exit> when |
800 | This is why the asynchronous backend explicitly calls C<CORE::exit> when |
801 | it is done (it will raise an exception under other circumstances, which |
801 | it is done (under other circumstances, such as when there is an I/O error |
802 | might lead to the process not exiting on it's own). |
802 | and there is outstanding data to write, it will log a fatal message via |
|
|
803 | L<AnyEvent::Log>, also causing the program to exit). |
803 | |
804 | |
804 | You can override this by specifying a function name to call via the C<done> |
805 | You can override this by specifying a function name to call via the C<done> |
805 | parameter instead. |
806 | parameter instead. |
806 | |
807 | |
807 | =back |
808 | =back |