view release on metacpan or  search on metacpan

README  view on Meta::CPAN

        Example:

           AnyEvent::Fork
              ->new_exec
              ->require ("Some::Module")
              ->run ("Some::Module::run", sub {
                 my ($fork_fh) = @_;
              });

THE "AnyEvent::Fork" CLASS
    This module exports nothing, and only implements a single class -
    "AnyEvent::Fork".

    There are two class constructors that both create new processes - "new"
    and "new_exec". The "fork" method creates a new process by forking an
    existing one and could be considered a third constructor.

    Most of the remaining methods deal with preparing the new process, by
    loading code, evaluating code and sending data to the new process. They
    usually return the process object, so you can chain method calls.

    If a process object is destroyed before calling its "run" method, then
    the process simply exits. After "run" is called, all responsibility is
    passed to the specified function.

    As long as there is any outstanding work to be done, process objects
    resist being destroyed, so there is no reason to store them unless you
    need them later - configure and forget works just fine.

    my $proc = new AnyEvent::Fork
        Create a new "empty" perl interpreter process and returns its
        process object for further manipulation.

        The new process is forked from a template process that is kept
        around for this purpose. When it doesn't exist yet, it is created by
        a call to "new_exec" first and then stays around for future calls.

    $new_proc = $proc->fork
        Forks $proc, creating a new process, and returns the process object
        of the new process.

        If any of the "send_" functions have been called before fork, then
        they will be cloned in the child. For example, in a pre-forked
        server, you might "send_fh" the listening socket into the template
        process, and then keep calling "fork" and "run".

    my $proc = new_exec AnyEvent::Fork
        Create a new "empty" perl interpreter process and returns its
        process object for further manipulation.

        Unlike the "new" method, this method *always* spawns a new perl
        process (except in some cases, see AnyEvent::Fork::Early for
        details). This reduces the amount of memory sharing that is
        possible, and is also slower.

        You should use "new" whenever possible, except when having a
        template process around is unacceptable.

        The path to the perl interpreter is divined using various methods -
        first $^X is investigated to see if the path ends with something
        that looks as if it were the perl interpreter. Failing this, the
        module falls back to using $Config::Config{perlpath}.

        The path to perl can also be overridden by setting the global
        variable $AnyEvent::Fork::PERL - it's value will be used for all
        subsequent invocations.

    $pid = $proc->pid
        Returns the process id of the process *iff it is a direct child of
        the process running AnyEvent::Fork*, and "undef" otherwise. As a
        general rule (that you cannot rely upon), processes created via
        "new_exec", AnyEvent::Fork::Early or AnyEvent::Fork::Template are
        direct children, while all other processes are not.

        Or in other words, you do not normally have to take care of zombies
        for processes created via "new", but when in doubt, or zombies are a
        problem, you need to check whether a process is a diretc child by
        calling this method, and possibly creating a child watcher or reap
        it manually.

    $proc = $proc->eval ($perlcode, @args)
        Evaluates the given $perlcode as ... Perl code, while setting @_ to
        the strings specified by @args, in the "main" package (so you can
        access the args using $_[0] and so on, but not using implicit "shit"
        as the latter works on @ARGV).

        This call is meant to do any custom initialisation that might be
        required (for example, the "require" method uses it). It's not
        supposed to be used to completely take over the process, use "run"
        for that.

        The code will usually be executed after this call returns, and there
        is no way to pass anything back to the calling process. Any
        evaluation errors will be reported to stderr and cause the process
        to exit.

        If you want to execute some code (that isn't in a module) to take
        over the process, you should compile a function via "eval" first,
        and then call it via "run". This also gives you access to any
        arguments passed via the "send_xxx" methods, such as file handles.
        See the "use AnyEvent::Fork as a faster fork+exec" example to see it
        in action.

        Returns the process object for easy chaining of method calls.

        It's common to want to call an iniitalisation function with some
        arguments. Make sure you actually pass @_ to that function (for
        example by using &name syntax), and do not just specify a function
        name:

           $proc->eval ('&MyModule::init', $string1, $string2);

    $proc = $proc->require ($module, ...)
        Tries to load the given module(s) into the process

        Returns the process object for easy chaining of method calls.

    $proc = $proc->send_fh ($handle, ...)
        Send one or more file handles (*not* file descriptors) to the
        process, to prepare a call to "run".