AnyEvent-Fork

 view release on metacpan or  search on metacpan

Fork.pm  view on Meta::CPAN

              open STDOUT, ">&", $output or die;
              open STDERR, ">&", $fh or die;

              exec @cmd;
           }
        ')
      ->send_fh ($output)
      ->send_arg ("/bin/echo", "hi")
      ->run ("run", my $cv = AE::cv);

   my $stderr = $cv->recv;

=head2 For stingy users: put the worker code into a C<DATA> section.

When you want to be stingy with files, you can put your code into the
C<DATA> section of your module (or program):

   use AnyEvent::Fork;

   AnyEvent::Fork
      ->new

Fork.pm  view on Meta::CPAN

to the strings specified by C<@args>, in the "main" package (so you can
access the args using C<$_[0]> and so on, but not using implicit C<shit>
as the latter works on C<@ARGV>).

This call is meant to do any custom initialisation that might be required
(for example, the C<require> method uses it). It's not supposed to be used
to completely take over the process, use C<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 C<eval> first, and then call
it via C<run>. This also gives you access to any arguments passed via the
C<send_xxx> methods, such as file handles. See the L<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

README  view on Meta::CPAN

                  open STDOUT, ">&", $output or die;
                  open STDERR, ">&", $fh or die;

                  exec @cmd;
               }
            ')
          ->send_fh ($output)
          ->send_arg ("/bin/echo", "hi")
          ->run ("run", my $cv = AE::cv);

       my $stderr = $cv->recv;

  For stingy users: put the worker code into a "DATA" section.
    When you want to be stingy with files, you can put your code into the
    "DATA" section of your module (or program):

       use AnyEvent::Fork;

       AnyEvent::Fork
          ->new
          ->eval (do { local $/; <DATA> })

README  view on Meta::CPAN

        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.