… | |
… | |
439 | You should use "new" whenever possible, except when having a |
439 | You should use "new" whenever possible, except when having a |
440 | template process around is unacceptable. |
440 | template process around is unacceptable. |
441 | |
441 | |
442 | The path to the perl interpreter is divined using various methods - |
442 | The path to the perl interpreter is divined using various methods - |
443 | first $^X is investigated to see if the path ends with something |
443 | first $^X is investigated to see if the path ends with something |
444 | that sounds as if it were the perl interpreter. Failing this, the |
444 | that looks as if it were the perl interpreter. Failing this, the |
445 | module falls back to using $Config::Config{perlpath}. |
445 | module falls back to using $Config::Config{perlpath}. |
446 | |
446 | |
447 | The path to perl can also be overriden by setting the global |
447 | The path to perl can also be overriden by setting the global |
448 | variable $AnyEvent::Fork::PERL - it's value will be used for all |
448 | variable $AnyEvent::Fork::PERL - it's value will be used for all |
449 | subsequent invocations. |
449 | subsequent invocations. |
450 | |
450 | |
451 | $pid = $proc->pid |
451 | $pid = $proc->pid |
452 | Returns the process id of the process *iff it is a direct child of |
452 | Returns the process id of the process *iff it is a direct child of |
453 | the process running AnyEvent::Fork*, and "undef" otherwise. |
453 | the process running AnyEvent::Fork*, and "undef" otherwise. As a |
|
|
454 | general rule (that you cannot rely upon), processes created via |
|
|
455 | "new_exec", AnyEvent::Fork::Early or AnyEvent::Fork::Template are |
|
|
456 | direct children, while all other processes are not. |
454 | |
457 | |
455 | Normally, only processes created via "AnyEvent::Fork->new_exec" and |
458 | Or in other words, you do not normally have to take care of zombies |
456 | AnyEvent::Fork::Template are direct children, and you are |
459 | for processes created via "new", but when in doubt, or zombies are a |
457 | responsible to clean up their zombies when they die. |
460 | problem, you need to check whether a process is a diretc child by |
458 | |
461 | calling this method, and possibly creating a child watcher or reap |
459 | All other processes are not direct children, and will be cleaned up |
462 | it manually. |
460 | by AnyEvent::Fork itself. |
|
|
461 | |
463 | |
462 | $proc = $proc->eval ($perlcode, @args) |
464 | $proc = $proc->eval ($perlcode, @args) |
463 | Evaluates the given $perlcode as ... Perl code, while setting @_ to |
465 | Evaluates the given $perlcode as ... Perl code, while setting @_ to |
464 | the strings specified by @args, in the "main" package. |
466 | the strings specified by @args, in the "main" package. |
465 | |
467 | |
… | |
… | |
547 | Even if not used otherwise, the socket can be a good indicator for |
549 | Even if not used otherwise, the socket can be a good indicator for |
548 | the existence of the process - if the other process exits, you get a |
550 | the existence of the process - if the other process exits, you get a |
549 | readable event on it, because exiting the process closes the socket |
551 | readable event on it, because exiting the process closes the socket |
550 | (if it didn't create any children using fork). |
552 | (if it didn't create any children using fork). |
551 | |
553 | |
|
|
554 | Compatibility to AnyEvent::Fork::Remote |
|
|
555 | If you want to write code that works with both this module and |
|
|
556 | AnyEvent::Fork::Remote, you need to write your code so that it |
|
|
557 | assumes there are two file handles for communications, which |
|
|
558 | might not be unix domain sockets. The "run" function should |
|
|
559 | start like this: |
|
|
560 | |
|
|
561 | sub run { |
|
|
562 | my ($rfh, @args) = @_; # @args is your normal arguments |
|
|
563 | my $wfh = fileno $rfh ? $rfh : *STDOUT; |
|
|
564 | |
|
|
565 | # now use $rfh for reading and $wfh for writing |
|
|
566 | } |
|
|
567 | |
|
|
568 | This checks whether the passed file handle is, in fact, the |
|
|
569 | process "STDIN" handle. If it is, then the function was invoked |
|
|
570 | visa AnyEvent::Fork::Remote, so STDIN should be used for reading |
|
|
571 | and "STDOUT" should be used for writing. |
|
|
572 | |
|
|
573 | In all other cases, the function was called via this module, and |
|
|
574 | there is only one file handle that should be sued for reading |
|
|
575 | and writing. |
|
|
576 | |
552 | Example: create a template for a process pool, pass a few strings, |
577 | Example: create a template for a process pool, pass a few strings, |
553 | some file handles, then fork, pass one more string, and run some |
578 | some file handles, then fork, pass one more string, and run some |
554 | code. |
579 | code. |
555 | |
580 | |
556 | my $pool = AnyEvent::Fork |
581 | my $pool = AnyEvent::Fork |
… | |
… | |
589 | with the communications socket. |
614 | with the communications socket. |
590 | |
615 | |
591 | The process object becomes unusable on return from this function - |
616 | The process object becomes unusable on return from this function - |
592 | any further method calls result in undefined behaviour. |
617 | any further method calls result in undefined behaviour. |
593 | |
618 | |
594 | The point of this method is to give you a file handle thta you cna |
619 | The point of this method is to give you a file handle that you can |
595 | pass to another process. In that other process, you can call |
620 | pass to another process. In that other process, you can call |
596 | "new_from_fh AnyEvent::Fork" to create a new "AnyEvent::Fork" object |
621 | "new_from_fh AnyEvent::Fork $fh" to create a new "AnyEvent::Fork" |
597 | from it, thereby effectively passing a fork object to another |
622 | object from it, thereby effectively passing a fork object to another |
598 | process. |
623 | process. |
599 | |
624 | |
600 | new_from_fh AnyEvent::Fork $fh # EXPERIMENTAL, MIGHT BE REMOVED |
625 | new_from_fh AnyEvent::Fork $fh # EXPERIMENTAL, MIGHT BE REMOVED |
601 | Takes a file handle originally rceeived by the "to_fh" method and |
626 | Takes a file handle originally rceeived by the "to_fh" method and |
602 | creates a new "AnyEvent:Fork" object. The child process itself will |
627 | creates a new "AnyEvent:Fork" object. The child process itself will |
… | |
… | |
747 | (part of this distribution). |
772 | (part of this distribution). |
748 | |
773 | |
749 | AnyEvent::Fork::Template, to create a process by forking the main |
774 | AnyEvent::Fork::Template, to create a process by forking the main |
750 | program at a convenient time (part of this distribution). |
775 | program at a convenient time (part of this distribution). |
751 | |
776 | |
|
|
777 | AnyEvent::Fork::Remote, for another way to create processes that is |
|
|
778 | mostly compatible to this module and modules building on top of it, but |
|
|
779 | works better with remote processes. |
|
|
780 | |
752 | AnyEvent::Fork::RPC, for simple RPC to child processes (on CPAN). |
781 | AnyEvent::Fork::RPC, for simple RPC to child processes (on CPAN). |
753 | |
782 | |
754 | AnyEvent::Fork::Pool, for simple worker process pool (on CPAN). |
783 | AnyEvent::Fork::Pool, for simple worker process pool (on CPAN). |
755 | |
784 | |
756 | AUTHOR AND CONTACT INFORMATION |
785 | AUTHOR AND CONTACT INFORMATION |