|Problems? Is your data what you think it is?|
Re: basic fork questionby stephen (Priest)
|on Jan 19, 2002 at 06:53 UTC||Need Help??|
(I've been out of the game for a bit, so all of this goes into the "if I recall correctly" category)
Whenever you do a fork() call, the system:
This is an oversimplification, and as such is totally inaccurate. :) Even so, it shows that every time you do a fork(), it costs time and (frequently) memory. Also, if you're processing a bunch of items and have to wait until they're all done before you move on to the next step, it's frequently no faster to fork off subprocesses than it is to do the whole thing step-by-step. (This is especially true if you're on a single-processor machine-- multithreading won't do it faster. It will just make all of your processes fight for time on the processor.)
This is only my opinion, but I would REALLY not fork off one process per record. Whether it would bog down an average PC would depend on how processor-intensive the task is.
If forking off background processes still looks good, it's generally a good idea to decide on a maximum number of threads, create them as necessary, and parcel out tasks to them as appropriate. I'll leave exactly how to do that to you. :)
By "how do I store this for use in the parent process", I think you mean "How do I get the value of a changed variable in a child process back to the parent process?" The answer is, not directly. Your child process is running in a completely different Perl interpreter, so there's no way to pass a variable. If you want to write a result back to the parent process, you'll need to write it via an open filehandle or named pipe. Look at the perlipc manpage for details.
The function you're looking for to wait until all the child processes are finished is the wait() function. You'd do it like so:
Trying to run it from 1 to 1000 bombs matters out at around 571 with this script, so once again, forking off 1000 children is a Bad Idea. :)