Re: Wait for background processes to complete
- From: pgodfrin <pgodfrin@xxxxxxxxx>
- Date: Fri, 18 Jan 2008 09:47:37 -0800 (PST)
Gentle Persons,
This was a lot of fun. I would like to respond to the various
observations, especially the ones about the Perl Documentation being
misleading.
To begin with, I apologize for my last post (the long one) - upon re-
reading it my language was not clear. I should have said "the
following code works" as opposed to simply "this works AND waits". I
was referring to the code below that sentence. Sorry.
To restate the original task I wanted to solve:
To be able to execute commands in the background and wait for their
completion.
The documentation I am referring to is http://perldoc.perl.org/.
If you search on the concept of "background processes" this
documentation points you to the following in the Language reference >
perlipc > Background Process :
<begin quote>
You can run a command in the background with:
system("cmd &");
The command's STDOUT and STDERR (and possibly STDIN, depending on your
shell) will be the same as the parent's. You won't need
to catch SIGCHLD because of the double-fork taking place (see below
for more details).
<end quote>
There is no further reference to a "double fork" (except in the
perlfaq8 and only in the context of zombies, which it says are not an
issue using system("cmd &") ). This is confusing.
The documentation for wait(), waitpid() and fork() do not explain that
the executing code should be placed in the "child" section of the if
construct. Some of the examples in perlipc show code occurring in both
the parent and the child section - so it is still not clear. If it
were, why was I insisting on trying to execute the "cp" command in the
parent section? So, thank you Peter for clearing that up. To be fair,
the only place where the "if" construct is indeed placed on paper (or
virtual paper) is the camel book - but it is also not clear where the
code should be placed. But clearly, that is clear now :).
Furthermore, while the perlipc section is quite verbose, nowhere is
the code snippet do {$x=wait; print "$x\n"} until $x==-1 or any
variation of that wait() call mentioned. There are references to a
while loop and the waitpid() function, but being in the context of a
signal handler and 'reaping' - it is not clear.
So, once again many thanks for the help. I would like to know, Peter,
are you in a position to amend the documentation? Also, the perlfaq8
does come closer to explaining, but it is simply not clear how the
fork process will emulate the Unix background operator (&). So how can
we make this better? How's about this:
In the perlipc, under background tasks. make the statement - "the call
system("cmd &") will run the cmd in the background, but will spawn a
shell to execute the command, dispatch the command, terminate the
shell and return to the calling program. The calling program will lose
the ability to wait for the process as is customary with the shell
script command 'wait'. In order to both execute one or more programs
in the background and have the calling program wait for the executions
to complete it will be necessary to use the fork() function."
Then in the fork section. Show a simple example like the ones we have
been working with AND show a simple approach to using the wait
function. Furthermore - add sample code to the wait() and fork()
functions that are simple and realistic, unlike the code same in the
waitpid() function.
In closing, it is perhaps non-intuitive to me that a fork process
should have the child section actually executing the code, but I ask
you how one can intuit that from the sample in the camel book and the
samples in the http://perldoc.perl.org/. To really drive the point
home, Xho's code:
fork or exec("cp $_ $_.old") ;
do {$x=wait;} until $x==-1 ;
Is STILL not intuitive that the child is executing the code!
All in all, with the collective help of y'all I been able to
successfully accomplish my goal, but man it was an uphill battle that
could have been very easily solved with better documentation. But -
what I can't figure out is why I had to embark on this journey in a
new posting - has no-one needed to do this before? Oh well...
so long and thanks for all the fish,
pg
.
- Follow-Ups:
- Re: Wait for background processes to complete
- From: Peter J. Holzer
- Re: Wait for background processes to complete
- References:
- Wait for background processes to complete
- From: pgodfrin
- Re: Wait for background processes to complete
- From: pgodfrin
- Re: Wait for background processes to complete
- From: Ben Morrow
- Re: Wait for background processes to complete
- From: grocery_stocker
- Re: Wait for background processes to complete
- From: Ben Morrow
- Re: Wait for background processes to complete
- From: grocery_stocker
- Re: Wait for background processes to complete
- From: Peter J. Holzer
- Wait for background processes to complete
- Prev by Date: how to put subroutines in separate files and call?
- Next by Date: Re: how to put subroutines in separate files and call?
- Previous by thread: Re: Wait for background processes to complete
- Next by thread: Re: Wait for background processes to complete
- Index(es):
Relevant Pages
|
|