view release on metacpan or  search on metacpan

README  view on Meta::CPAN

        done => $function (default: "CORE::exit")
            The function to call when the asynchronous backend detects an
            end of file condition when reading from the communications
            socket *and* there are no outstanding requests. It is ignored by
            the synchronous backend.

            By overriding this you can prolong the life of a RPC process
            after e.g. the parent has exited by running the event loop in
            the provided function (or simply calling it, for example, when
            your child process uses EV you could provide EV::run as "done"
            function).

            Of course, in that case you are responsible for exiting at the
            appropriate time and not returning from

        async => $boolean (default: 0)
            The default server used in the child does all I/O blockingly,
            and only allows a single RPC call to execute concurrently.

            Setting "async" to a true value switches to another
            implementation that uses 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 $rpc function.

            If you want to pre-load the actual back-end modules to enable
            memory sharing, then you should load "AnyEvent::Fork::RPC::Sync"
            for synchronous, and "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.

        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 and requires
            no extra modules (the "AnyEvent::Fork::RPC" distribution does
            not provide these extra serialiser 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 string and
            must return the original list of values.

            If you need an external module for serialisation, then you can
            either pre-load it into your AnyEvent::Fork process, or you can
            add a "use" or "require" statement into the serialiser string.
            Or both.

            Here are some examples - all of them are also available as
            global variables that make them easier to use.

            $AnyEvent::Fork::RPC::STRING_SERIALISER - octet strings only
                This serialiser (currently the default) concatenates
                length-prefixes octet strings, and is the default. That
                means you can only pass (and return) strings containing
                character codes 0-255.

                The main advantages of this serialiser are the high speed
                and that it doesn't need another module. The main
                disadvantage is that you are very limited in what you can
                pass - only octet strings.

                Implementation:

                   (
                      sub { pack   "(w/a*)*", @_ },
                      sub { unpack "(w/a*)*", shift }
                   )

            $AnyEvent::Fork::RPC::CBOR_XS_SERIALISER - uses CBOR::XS
                This serialiser creates CBOR::XS arrays - you have to make
                sure the CBOR::XS module is installed for this serialiser to
                work. It can be beneficial for sharing when you preload the
                CBOR::XS module in a template process.

                CBOR::XS is about as fast as the octet string serialiser,
                but supports complex data structures (similar to JSON) and
                is faster than any of the other serialisers. If you have the
                CBOR::XS module available, it's the best choice.

                The encoder enables "allow_sharing" (so this serialisation
                method can encode cyclic and self-referencing data
                structures).

                Implementation:

                   use CBOR::XS ();
                   (
                      sub {    CBOR::XS::encode_cbor_sharing \@_ },
                      sub { @{ CBOR::XS::decode_cbor shift } }
                   )

            $AnyEvent::Fork::RPC::JSON_SERIALISER - uses JSON::XS or JSON
                This serialiser creates JSON arrays - you have to make sure
                the JSON module is installed for this serialiser to work. It
                can be beneficial for sharing when you preload the JSON
                module in a template process.

                JSON (with JSON::XS installed) is slower than the octet
                string serialiser, but usually much faster than Storable,
                unless big chunks of binary data need to be transferred.

                Implementation:

                   use JSON ();
                   (
                      sub {    JSON::encode_json \@_ },
                      sub { @{ JSON::decode_json shift } }
                   )