On Dec 20, 2003, at 12:58 AM, R. Joseph Newton wrote:
Dan Anderson wrote:
I'm creating an app that uses forks in a number of places to do things
quicker. Unfortunately, I have a bad habit of accidentally fork bombing
my box.
This is a pretty good sign that you are over-using the fork command.
Efficiently designed programs can usually run pretty well without extra
forking. If a certain process can do its work independtently of the rest of
the program, and one or the other needs to wait for some external event
[such as user input], that would be a good case for using a fork, very
carefully. I can't see a good reason to ever fork processes from inside a
loop. That is just asking for trouble.
Many (I would dare so most) real-world forking examples involve calling fork() in a (albeit small) loop. Think pre-fork servers, or maintaining a pool of helper children, etc. This is hands-down the easiest strategy for dealing with slow operations that never block (disk IO) and is often easier to understand than writing an event-based framework for IO that can be done in a non-blocking fashion (network IO).
Obviously forking in a tight loop with no controls over your child dispatching is a bad thing, but I assume that Dan's question was along the lines of _accidentally_ fork bombing his machine with code like
for(1...$num_children) {
unless(fork()) {
child_main();
# oops forgot to exit here
}
}which will fork-bomb your machine.
As far as preventing errors like that in development, you can use something like Proc::Queue (I've never used it, but it seems to be a direct fit). Alterntively you can monitor the process table and ensure that you do not exceed a certain number of processes in your parent process' process group.
George
// George Schlossnagle // Postal Engine -- http://www.postalengine.com/ // Ecelerity: fastest MTA on earth
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
