Note that this means that the process as a whole will not exit unless all running pseudo-processes have exited. See below for some limitations with open filehandles. All open handles are dup -ed in pseudo-processes, so that closing any handles in one process does not affect the others. See below for some limitations. In the eyes of the operating system, pseudo-processes created via the fork emulation are simply threads in the same process.
This means that any process-level limits imposed by the operating system apply to all pseudo-processes taken together. This includes any limits imposed by the operating system on the number of open file, directory and socket handles, limits on disk space usage, limits on memory size, limits on CPU utilization etc. If the parent process is killed either using Perl's kill builtin, or using some external means all the pseudo-processes are killed as well, and the whole process exits.
During the normal course of events, the parent process and every pseudo-process started by it will wait for their respective pseudo-children to complete before they exit. This means that the parent and every pseudo-child created by it that is also a pseudo-parent will only exit after their pseudo-children have exited. Starting with Perl 5. For example, consider the following code:. This limitation arises from fundamental technical difficulties in cloning and restarting the stacks used by the Perl parser in the middle of a parse.
Any filehandles open at the time of the fork will be dup -ed. Thus, the files can be closed independently in the parent and child, but beware that the dup -ed handles will still share the same seek pointer.
Changing the seek position in the parent will change it in the child and vice-versa. One can avoid this by opening files that need distinct seek pointers separately in the child. On some operating systems, notably Solaris and Unixware, calling exit from a child process will flush and close open filehandles in the parent, thereby corrupting the filehandles. Please consult your system's manpages for more information on this.
Perl will completely read from all open directory handles until they reach the end of the stream. It will then seekdir back to the original location and all future readdir requests will be fulfilled from the cache buffer. That means that neither the directory handle held by the parent process nor the one held by the child process will see any changes made to the directory after the fork call. Note that rewinddir has a similar limitation on Windows and will not force readdir to read the directory again either.
The parent process will skip the block of the if-statement and will execute the code after it. At one point the parent process will call wait , that will only return after the child process exits. They are there so you can enable each one of them separately to observe two things: If the sleep is enabled in the child process inside the if block then the parent will arrive to the wait call much sooner than the child finishes. You will see it really waits there and the last print line from the parent will only appear after the child process finished.
On the other hand, if you enable the sleep in the parent process only, then the child will exit long before the parent reaches the call to wait. So when the parent finally calls wait , it will return immediately and return the process id of the child that has finished earlier. This is important, as this means the signal that the parent process received marking the end of the child process has also waited for the parent to "collect" it.
This will be especially important in the next example, where we create several child processes and we want to make sure we wait for all of them. Normally it is the same number as we wanted to fork, but in case one of the forks is not successful we don't want to wait for too many child processes. As the child processes exit, each one of them sends a signal to the parent. These signals wait in a queue handled by the operating system and the call to wait will return then next item from that queue.
IF the queue is empty it will wait for a new signal to arrive. So in the last part of the code we call wait exactly the same time as the number of successful forks. In the part of the parent process in the if-block , we just counted the forks.
In the child process in the else-block we are supposed to do the real work. Here replaced by a call to sleep. I am sure you are also familiar with people who go to work and then sleep there On the other hand there is a waitpid call that we don't use in our examples, but that will wait for the end of a specific child process based on its process ID PID. Spreading load to several cores Lastly, let's see an example how we can spread load to several cores in your CPU.
For this probably the best tool to use is the htop command in Linux. Then open a separate terminal and launch htop. At the top it should show several numbered rows.
The fork function is used to clone a current process. This call create a new process running the same program at the same point. It returns the child pid to the parent process, 0 to the child process, or under if the fork is unsuccessful.
You can use exec function within a process to launch the requested executable, which will be executed in a separate process area and exec will wait for it to complete before exiting with the same exit status as that process.
0コメント