… | |
… | |
60 | # or anything we usually couldn't do in a process forked normally. |
60 | # or anything we usually couldn't do in a process forked normally. |
61 | while (my $socket = $listener->accept) { |
61 | while (my $socket = $listener->accept) { |
62 | # do sth. with new socket |
62 | # do sth. with new socket |
63 | } |
63 | } |
64 | } |
64 | } |
|
|
65 | |
|
|
66 | ################################################################## |
|
|
67 | # use AnyEvent::Fork as a faster fork+exec |
|
|
68 | |
|
|
69 | # this runs /bin/echo hi, with stdout redirected to /tmp/log |
|
|
70 | # and stderr to the communications socket. it is usually faster |
|
|
71 | # than fork+exec, but still let's you prepare the environment. |
|
|
72 | |
|
|
73 | open my $output, ">/tmp/log" or die "$!"; |
|
|
74 | |
|
|
75 | AnyEvent::Fork |
|
|
76 | ->new |
|
|
77 | ->eval (' |
|
|
78 | sub run { |
|
|
79 | my ($fh, $output, @cmd) = @_; |
|
|
80 | |
|
|
81 | # perl will clear close-on-exec on STDOUT/STDERR |
|
|
82 | open STDOUT, ">&", $output or die; |
|
|
83 | open STDERR, ">&", $fh or die; |
|
|
84 | |
|
|
85 | exec @cmd; |
|
|
86 | } |
|
|
87 | ') |
|
|
88 | ->send_fh ($output) |
|
|
89 | ->send_arg ("/bin/echo", "hi") |
|
|
90 | ->run ("run", my $cv = AE::cv); |
|
|
91 | |
|
|
92 | my $stderr = $cv->recv; |
65 | |
93 | |
66 | =head1 DESCRIPTION |
94 | =head1 DESCRIPTION |
67 | |
95 | |
68 | This module allows you to create new processes, without actually forking |
96 | This module allows you to create new processes, without actually forking |
69 | them from your current process (avoiding the problems of forking), but |
97 | them from your current process (avoiding the problems of forking), but |
… | |
… | |
493 | } |
521 | } |
494 | |
522 | |
495 | =item $proc = $proc->eval ($perlcode, @args) |
523 | =item $proc = $proc->eval ($perlcode, @args) |
496 | |
524 | |
497 | Evaluates the given C<$perlcode> as ... perl code, while setting C<@_> to |
525 | Evaluates the given C<$perlcode> as ... perl code, while setting C<@_> to |
498 | the strings specified by C<@args>. |
526 | the strings specified by C<@args>, in the "main" package. |
499 | |
527 | |
500 | This call is meant to do any custom initialisation that might be required |
528 | This call is meant to do any custom initialisation that might be required |
501 | (for example, the C<require> method uses it). It's not supposed to be used |
529 | (for example, the C<require> method uses it). It's not supposed to be used |
502 | to completely take over the process, use C<run> for that. |
530 | to completely take over the process, use C<run> for that. |
503 | |
531 | |
504 | The code will usually be executed after this call returns, and there is no |
532 | The code will usually be executed after this call returns, and there is no |
505 | way to pass anything back to the calling process. Any evaluation errors |
533 | way to pass anything back to the calling process. Any evaluation errors |
506 | will be reported to stderr and cause the process to exit. |
534 | will be reported to stderr and cause the process to exit. |
|
|
535 | |
|
|
536 | If you want to execute some code to take over the process (see the |
|
|
537 | "fork+exec" example in the SYNOPSIS), you should compile a function via |
|
|
538 | C<eval> first, and then call it via C<run>. This also gives you access to |
|
|
539 | any arguments passed via the C<send_xxx> methods, such as file handles. |
507 | |
540 | |
508 | Returns the process object for easy chaining of method calls. |
541 | Returns the process object for easy chaining of method calls. |
509 | |
542 | |
510 | =cut |
543 | =cut |
511 | |
544 | |
… | |
… | |
587 | $self |
620 | $self |
588 | } |
621 | } |
589 | |
622 | |
590 | =item $proc->run ($func, $cb->($fh)) |
623 | =item $proc->run ($func, $cb->($fh)) |
591 | |
624 | |
592 | Enter the function specified by the fully qualified name in C<$func> in |
625 | Enter the function specified by the function name in C<$func> in the |
593 | the process. The function is called with the communication socket as first |
626 | process. The function is called with the communication socket as first |
594 | argument, followed by all file handles and string arguments sent earlier |
627 | argument, followed by all file handles and string arguments sent earlier |
595 | via C<send_fh> and C<send_arg> methods, in the order they were called. |
628 | via C<send_fh> and C<send_arg> methods, in the order they were called. |
596 | |
629 | |
597 | If the called function returns, the process exits. |
630 | The function name should be fully qualified, but if it isn't, it will be |
|
|
631 | looked up in the main package. |
598 | |
632 | |
599 | Preparing the process can take time - when the process is ready, the |
633 | If the called function returns, doesn't exist, or any error occurs, the |
|
|
634 | process exits. |
|
|
635 | |
|
|
636 | Preparing the process is done in the background - when all commands have |
600 | callback is invoked with the local communications socket as argument. |
637 | been sent, the callback is invoked with the local communications socket |
|
|
638 | as argument. At this point you can start using the socket in any way you |
|
|
639 | like. |
601 | |
640 | |
602 | The process object becomes unusable on return from this function. |
641 | The process object becomes unusable on return from this function - any |
|
|
642 | further method calls result in undefined behaviour. |
603 | |
643 | |
604 | If the communication socket isn't used, it should be closed on both sides, |
644 | If the communication socket isn't used, it should be closed on both sides, |
605 | to save on kernel memory. |
645 | to save on kernel memory. |
606 | |
646 | |
607 | The socket is non-blocking in the parent, and blocking in the newly |
647 | The socket is non-blocking in the parent, and blocking in the newly |
608 | created process. The close-on-exec flag is set on both. Even if not used |
648 | created process. The close-on-exec flag is set in both. |
|
|
649 | |
609 | otherwise, the socket can be a good indicator for the existence of the |
650 | Even if not used otherwise, the socket can be a good indicator for the |
610 | process - if the other process exits, you get a readable event on it, |
651 | existence of the process - if the other process exits, you get a readable |
611 | because exiting the process closes the socket (if it didn't create any |
652 | event on it, because exiting the process closes the socket (if it didn't |
612 | children using fork). |
653 | create any children using fork). |
613 | |
654 | |
614 | Example: create a template for a process pool, pass a few strings, some |
655 | Example: create a template for a process pool, pass a few strings, some |
615 | file handles, then fork, pass one more string, and run some code. |
656 | file handles, then fork, pass one more string, and run some code. |
616 | |
657 | |
617 | my $pool = AnyEvent::Fork |
658 | my $pool = AnyEvent::Fork |