The classic use of fork() is in client-server applications. The server just listens for new inbound connections and when one is detected, it accepts the connection to this new client and makes a "copy of itself" to handle whatever business this client wants. This "new copy" is known as a child process. The code is simplified as the server doesn't know how many "children" it has and each child deals with one client. Roughly speaking, this "start new copy of myself" is fork(). On Windows, this doesn't quite work this way and details get complicated, but same idea applies. There are a lot of "pesky details" to building good, robust client server applications.
One basic thing is: don't use system() or exec() if you can call a Perl module or function to do what you want. For example, you wouldn't want to call a shell command like 'ls' on Unix or 'dir' on Windows to list a directory.
Any way in programming fork is not a dining utensil, it is more like a "fork in the road".
| [reply] |
[ I don't understand the underlying intent, so I'll answer the questions as asked. ]
Yes, it's available to be called. And whenever you want to.
| [reply] |
As a programmer we can use fork when we eat. | [reply] |
if you're new to forking within a process look at a fork interface such as Proc::Fork
Remember to always wait for your child processes to terminate (or kill them) before you exit i.e. waitpid $childPID, 0;
Good luck.
| [reply] |
You may wish to consider whether the fork in question is is any good. I have heard it said that there is nothing like a good fork. Though it is also said that even a mediocre fork is better than none at all. Bad forks, on the other hand, can generate a lot of mess and possibly dry cleaning. Does this help at all ?
Furthermore, never forget: "there is no spoon". So keep a close eye on your fork, lest some bugger pinches that as well.
Beyond those general observations, it is hard to offer much more useful advice in the absence of any context. Perhaps a more specific question will yield more immediately useful information...
| [reply] |