Hi wren,
Thanks. I know better now.
I will try to fix the problem within my time limit.
Best wishes,
Ted zeng
On 8/2/06 1:18 AM, "wren ng thornton" <[EMAIL PROTECTED]> wrote:
> --- quoth Ted Zeng <[EMAIL PROTECTED]>:
>> Originally, my perl script launches Eggplant as a
>> child process (use ``, not an independent process.)
>
> Actually ``, aka qx(), does spawn an independant
> process. Try running:
>
> perl -e'`sleep 6000`;' &
>
> and then doing a `ps` to see. But the semantics of
> qx() mean that the forking, execing, and capturing of
> output are hidden from the programmer. Same goes for
> using system().
>
> Because of the semantics of qx() and system(), there's
> no way to capture the pid of the spawned process--
> that's all handled behind the scenes. If you don't
> trust the children to return properly, then you need
> to use fork() and exec() explicitly with something
> like the following:
>
> #!/usr/bin/env perl
> print "$$: noone in here but us chickens\n";
> $pid = fork();
> print "$$: I got $pid\n";
> if ($pid == 0) {
> print "$$: child is execing\n";
> exec 'sleep', 10;
> } else {
> print "$$: parent is waiting\n";
> sleep 5;
> print "$$: kids these days! (killing $pid)\n";
> kill 9, $pid;
> }
> __END__
>
> You can watch this in another shell with a ps. You can
> also use elements of %SIG for the first argument to
> kill() but `sleep` so happens to ignore everything. Do
> note that the interleaving of the process scheduling
> after calling fork() is unpredictable, even if it
> appears reliable over a few runs. Even the order in
> which processes return from a call to fork() is
> unpredictable.
>
> Unfortunately with this approach, capturing the output
> of the child is harder. And of course you'll want to
> verify that the child is running too long before
> killing it in your version.
>
> Live well,
> ~wren
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
