Creating Child without overhead of Parent

cxbast has asked for the wisdom of the Perl Monks concerning the following question:

What I need is for a parent process to create a child that is not merely a copy of the parent. I have a parent process that will have a lot of overhead and the child needs to be free of that overhead. Also, I need the parent to wait until the child is done before exiting the script.

The code I have does not wait. My assumption is that getting the parent of 1 means that I am getting a child without the overhead of the parent.

Code is Below

# Fork the process as its own parent. I am assuming by 
# recieving a parent of 1 that the Child is not just a copy
# of the parent. 


unless (fork)
 {
  # Create first child
  unless (fork)
   {
    # Create Second Child
    sleep 1 until getppid == 1;
    # Execute our command 
    exec "distill mypsfile.ps";
    exit 0;
   }

  exit 0;
 }

 # Wait for the first child to be reaped 
 # How can we make this wait until the exec statement 
 # has completed before exiting ?????????
 wait;
[download]

edit (broquaint): changed <pre> <code> tags

Comment on Creating Child without overhead of Parent Download Code

Replies are listed 'Best First'.
Re: Creating Child without overhead of Parent by broquaint (Abbot) on Jun 25, 2004 at 03:59 UTC
If you've got an OS supporting Copy-On-Write forking, then the child is unlikely to be very large unless significant changes are made to large data structures etc. In your particular case it would seem simpler just to use a `system` since you're `fork`ing and `wait`ing for the child to return anyway. HTH `_________ broquaint`	[reply]
Re^2: Creating Child without overhead of Parent (vfork) by jeffa (Bishop) on Jun 25, 2004 at 15:29 UTC
And in the unlikely event that your OS does not support Copy-On-Write (but does support fork ...) then look into the `vfork()` system call. UPDATE: s/threads/fork/ ... silly /me jeffa L-LL-L--L-LL-L--L-LL-L-- -R--R-RR-R--R-RR-R--R-RR B--B--B--B--B--B--B--B-- H---H---H---H---H---H--- (the triplet paradiddle with high-hat)	[reply]
Re: Creating Child without overhead of Parent by Crackers2 (Parson) on Jun 25, 2004 at 05:51 UTC
I might be wrong, but I don't think your double fork is doing you any good. On the contrary, on systems where you don't have the COW broquaint is talking about, you'll get even more overhead than you already had The first fork() will duplicate the perl environment completely, and then the second fork() will duplicate that one. The first child being alive or not won't change any of that. It might also help to elaborate a bit more on what you mean by overhead. Any extra memory used by the perl copy of the child will be released by the exec, so that's not something to worry about really. And at least on linux there's no timeslice penalty or anything like that for being the child of a resource hog.	[reply]
Re^2: Creating Child without overhead of Parent (double fork) by jeffa (Bishop) on Jun 25, 2004 at 15:32 UTC
Indeed, a double fork here is only needed if you need to collect the exit status of the child without having the server wait for the status. The server forks the child to do the work, but the child forks another child (grandchild), giving the actual work to that grandchild and instead carring the burden of idling instead of making the server idle. When the grandchild has finished the work, the child collects the status and sends it back to the server. jeffa L-LL-L--L-LL-L--L-LL-L-- -R--R-RR-R--R-RR-R--R-RR B--B--B--B--B--B--B--B-- H---H---H---H---H---H--- (the triplet paradiddle with high-hat)	[reply]
Re: Creating Child without overhead of Parent by skyknight (Hermit) on Jun 25, 2004 at 13:43 UTC
Pretty much all modern OSes provide for very light weight forking, using Copy On Write as Broquaint mentions. What this means is that sections of the memory of the child process are references to the memory of the parent process, up until the point where either process writes to a particular memory section, at which point it is copied and the child process proceeds to have its memory references to that section refer to the copy. If this were not the case, then the fork/exec paradigm would be woefully expensive. As it stands, doing a fork/exec does not chew up any real overhead because the child process starts, and then is immediately wiped by the exec. I think that this is a reason for operating systems to favor giving the child process priority to run, since if it is going to exec some other program, this lets it get it off quickly, before the parent process can write to any memory, thus forcing the child to have a copy of it made.	[reply]